FreeIPA and Samba 3 Integration

FreeIPA makes a pretty excellent backend for Samba 3. While all the information one needs to set this up is available online, I wasn’t able to find it all  in one location so I’ve decided to try my best at filling that gap here on techslaves.org. Hopefully this short guide will aid those trying to piece together the various parts necessary to integrate FreeIPA v2 and Samba 3, at least until FreeIPA v3 where there is talk of enabling Samba integration with a simple command line argument to the “ipa-server-install” script.

Not for Domains

It’s important to keep in mind that these instructions are not for a integrating FreeIPA with a Samba domain controller but merely a Samba file server. My understanding is that FreeIPA will never conveniently/properly support the necessary bits to make it a suitable backend for a Samba 3 PDC. I believe FreeIPA will eventually look towards Samba 4 integration (using Domain trusts) for this kind of integration but don’t quote me on that. Either way, these instructions are not for Samba domain controllers, just Samba file servers.

The Assumptions

There are some basic assumptions that these instructions make.

  • FreeIPA is installed and functional
  • You have a general idea of how to use LDAP command line tools
  • If you have a nice GUI LDAP browser, you can use it to apply the example LDIFs and edit the tree instead of the ldap CLI tools
  • The LDAP commands are executed on the FreeIPA server
  • Samba and FreeIPA are installed on the same server (although it shouldn’t be difficult to use TLS encryption with separate servers)
  • Your LDAP suffix is “dc=domain,dc=tld”
  • You know the difference between the “admin” account and the directory manager and their passwords

The Goods

Let’s not beat around the bush any further.

  1. Determine your Samba server SID by executing the following command while smbd is running and jot it down:
root@ipaserver:~
# net getlocalsid
SID for IPASERVER domain  is: S-1-5-21-3180075094-3458813485-3821849995
  1. With the “admin” kerberos ticket, add two attributes to “cn=ipaConfig,dc=etc,dc=domain,dc=tld” that tell FreeIPA to setup each account as a Samba account and each group as a Samba group:
ldapmodify -Y GSSAPI <<EOF
dn: cn=ipaconfig,cn=etc,dc=domain,dc=tld
changetype: modify
add: ipaUserObjectClasses
ipaUserObjectClasses: sambaSAMAccount
-
add: ipaGroupObjectClasses
ipaGroupObjectClasses: sambaGroupMapping
EOF
  1. With the directory manager password and the Samba SID you jotted down from above, create an instance of the 389 DS DNA plugin that will automatically generate SIDs for your users and groups which are necessary for use with Samba:
ldapadd -x -D "cn=Directory Manager" -W <<EOF
dn: cn=SambaGroupSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
dnatype: sambaSID
dnaprefix: S-1-5-21-3180075094-3458813485-3821849995-
dnainterval: 1
dnamagicregen: assign
dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping))
dnascope: dc=domain,dc=tld
cn: SambaSid
dnanextvalue: 15277
EOF

The thing to note here is that the “dnaprefix” is set to the SID your jotted down… PLUS a hyphen (“-“) appended to the end!

  1. Now we have to start modifying the FreeIPA API, CLI and WebUI to allow us to specify the “sambaGroupType” attribute at group creation time. We have to set “sambaGroupType” because it is a required attribute for the objectClass “sambaGroupMapping” which we are automatically adding to every group with the “ipaGroupObjectClasses” setting from earlier.

Although the value is going to be “4” for every conceivable case in this non-domain configuration, I was not able to figure out how to make the DNA plugin insert static values like it can set incrementing values so I decided to allow setting it through the CLI and WebUS with defaults enabled instead. If anyone knows how to setup 389 to automatically add an attribute with a static value upon DN creation of DNs with specific objectClasses, please tell me.

There are a few steps required to make this CLI/UI stuff happen but the FreeIPA developers have actually made this quite simple.

The rule is: Extend the FreeIPA schema first, then the CLI, then the WebUI.

4.1. Extend the FreeIPA schema with a custom field by adding the attribute “ipaCustomFields” with a value of “Samba Group Type,sambagrouptype,true” to “cn=ipaConfig,dc=etc,dc=domain,dc=tld” with an “admin” kerberos ticket:

ldapmodify -Y GSSAPI <<EOF
dn: cn=ipaconfig,cn=etc,dc=domain,dc=tld
changetype: add
add: ipaCustomFields
ipaCustomFields: "Samba Group Type,sambagrouptype,true"
EOF

As there can only be one “ipaCustomFields” attribute, if you have multiple custom fields you need to separate each definition with a “$” like so: “Samba Group Type,sambagrouptype,true$Description,attrname,isrequiredboolean”.

4.2. Extend the CLI for groups by editing the python file “/…/site-packages/ipalib/plugins/group.py” to define the custom field and specify a default if not implicitly defined (diff):

--- group.py.orig  2011-08-15 14:59:48.570715207 -0700
+++ group.py    2011-08-16 12:43:43.493236507 -0700
@@ -118,6 +118,13 @@
             label=_('GID'),
             doc=_('GID (use this option to set it manually)'),
         ),
+        Int('sambagrouptype',
+            cli_name='sgt',
+            label=_('Samba Group Type'),
+            doc=_('Samba Group Type (default is 4)'),
+            default=4,
+            autofill=True,
+        ),
     )
 
 api.register(group)

Important: Restart “httpd” at this point!

4.3. Test the CLI. With an “admin” (or equivalent priv) kerberos ticket, try creating a new group:

account@ipaserver:~
$ ipa group-add testgrp --desc="Testing the group.py CLI mods"
---------------------
Added group "testgrp"
---------------------
  Group name: testgrp
  Description: Testing the group.py CLI mods
  GID: 1234500010
  Samba Group Type: 4

4.4 With the CLI functioning properly, we can move on to extending the WebUI. To extend the WebUI for group attributes, edit “/usr/share/ipa/ui/group.js” like so (diff):

--- group.js.orig  2011-08-15 10:01:28.515209121 -0700
+++ group.js    2011-08-16 13:52:59.587352034 -0700
@@ -34,6 +34,7 @@
                 column({name: 'cn'}).
                 column({name: 'gidnumber'}).
                 column({name: 'description'}).
+                column({name: 'sambagrouptype'}).
                 dialog(
                     IPA.add_dialog({
                         'name': 'add',
@@ -41,6 +42,7 @@
                     }).
                         field(IPA.text_widget({name: 'cn', undo: false})).
                         field(IPA.text_widget({name: 'description', undo: false})).
+                        field(IPA.select_widget({name: 'sambagrouptype', undo: false, options: [{label: 'Local', value: 4}, {label: 'Domain', value: 2}]})).
                         field(IPA.checkbox_widget({
                             name: 'posix',
                             label: IPA.messages.objects.group.posix,
@@ -56,6 +58,7 @@
                     }).
                         input({name: 'cn' }).
                         input({name: 'description'}).
+                        input({name: 'sambagrouptype'}).
                         input({name: 'gidnumber' }))).
         facet(
             IPA.group_member_user_facet({

And then these the WebUI to ensure that you can both see the attribute in the group list, but also add it via the select widget added to the new/edit group dialog.

That should be it. Questions, comments, suggestions, correction and more… all are welcome!

9 thoughts on “FreeIPA and Samba 3 Integration

    1. The object cn=ipaconfig already exists, so you might need to change up the ldif a little. I am running freeipa 4.2 on CentOS 7.2.

      Use this:

      ldapmodify -Y GSSAPI <<EOF
      dn: cn=ipaconfig,cn=etc,dc=domain,dc=tld
      changetype: modify
      add: ipaCustomFields
      ipaCustomFields: “Samba Group Type,sambagrouptype,true”
      EOF

  1. Whilst attempting to patch the group.js it’s became quickly clear that the curent group.js file has been updated and changed quite significantly.

    It looks like they’ve re-organised the layout of said group.js file and it’s nigh impossible to quite nail where the selector content and the results of the selector fit in to their new .js (not a JS expert here as you can imagine) is there any hints you or help you could possibly pass on to us poor struggling to get Samba 3 souls here?

    The .py and everything else works like a charm but it’s just that last part we’re banging heads about.

    1. I got it to work, although the samba group type column in the group list is empty. Here are the diffs to the files I had to edit:
      --- /usr/lib/python2.6/site-packages/ipalib/plugins/group.py.orig 2015-03-18 04:35:51.702586747 -0400
      +++ /usr/lib/python2.6/site-packages/ipalib/plugins/group.py 2015-03-18 04:39:48.987069967 -0400
      @@ -160,6 +160,13 @@
      doc=_('GID (use this option to set it manually)'),
      minvalue=1,
      ),
      + Int('sambagrouptype',
      + cli_name='sgt',
      + label=_('Samba Group Type'),
      + doc=_('Samba Group Type (default is 4)'),
      + default=4,
      + autofill=True,
      + ),
      )

      --- /usr/lib/python2.6/site-packages/ipalib/plugins/group.py.orig 2015-03-18 04:35:51.702586747 -0400
      +++ /usr/lib/python2.6/site-packages/ipalib/plugins/group.py 2015-03-18 04:39:48.987069967 -0400
      @@ -160,6 +160,13 @@
      doc=_('GID (use this option to set it manually)'),
      minvalue=1,
      ),
      + Int('sambagrouptype',
      + cli_name='sgt',
      + label=_('Samba Group Type'),
      + doc=_('Samba Group Type (default is 4)'),
      + default=4,
      + autofill=True,
      + ),
      )

      api.register(group)
      [root@ipa samba3_mods]# cat group.js.diff
      --- /usr/share/ipa/ui/group.js.orig 2015-03-18 04:42:27.878719032 -0400
      +++ /usr/share/ipa/ui/group.js 2015-03-18 05:11:49.136897446 -0400
      @@ -37,7 +37,8 @@
      columns: [
      'cn',
      'gidnumber',
      - 'description'
      + 'description',
      + 'sambagrouptype'
      ]
      }).
      details_facet({
      @@ -61,7 +62,12 @@
      posixgroup: IPA.messages.objects.group.posix
      }
      },
      - 'gidnumber'
      + 'gidnumber',
      + {
      + type: 'select',
      + options: [{label: 'Local', value: 4}, {label: 'Domain', value: 2}],
      + name: 'sambagrouptype'
      + }
      ]
      }
      ],
      @@ -169,7 +175,12 @@
      }
      ]
      },
      - 'gidnumber'
      + 'gidnumber',
      + {
      + type: 'select',
      + options: [{label: 'Local', value: 4}, {label: 'Domain', value: 2}],
      + name: 'sambagrouptype'
      + }
      ]
      });
      };

      I hope you can read it without the correct formatting…

  2. @Martin: Better (extremely) late than never but… did you restart httpd after editing group.py?

    @David: You’re not missing any part of the article, this is it. The samba configuration basically looks like any other samba configuration with an “ldapsam” backend. Hope that helps. If not, I can point you to some articles about configuring samba for LDAP authentication.

  3. This is a great tutorial for the IPASERVER configuration side, but apparently says nothing about the SAMBA configuration side.

    How to configure SAMBA to use the IPASERVER?

    Thanks for your very interesting article. Am I missing the second part of it somewhere?

  4. Hello. Excellent guide. Unfortunately I got stuck…

    When I come to point 4.3 I get:

    ipa: ERROR: Unknown option: sambagrouptype

    The only thing I’ve done differently (as far as I can tell) is that the samba server is a separate machine than the IPA-server but I’ve verified that it works so far that I can do, for example, getent passwd admin so apparently IPA itself is working properly.

    Any suggestion what has gone wrong?

  5. Thanks, this looks like exactly what I need.
    I have one question though: how many of these changes will get propagated to the rest of the FreeIPA cluster automatically? (assuming there are more than one FreeIPA servers in the network)

Leave a Reply

Your email address will not be published. Required fields are marked *