# HowTo: Samba and AD auth via rfc2307 and idmap_ad

## msalerno

I started my battle with AD/Linux integration quite a while ago, and I have finally picked it back up and WON!  So here are some notes and configs.

I decided to go with a winbind approach, here is a good artilce describing why: http://technet.microsoft.com/en-us/magazine/2008.12.linux.aspx#id0060014

It's a beautiful thing, all UID's and GID's are stored in AD rather than locally on the linux boxes!

The company I work for has a Windows 2003 R2 AD environment extended with rfc2307 attributes which is more common now that MS includes it by default.  All you need to do is populate the required attributes.

Here are the attributes you need to populate for users to be able to log in:

For Groups: gidNumber

For Users: gecos gidNumber loginShell uidNumber unixHomeDirectory

I started the UID's and GID's at 20,000 so that they dont conflict with any of the local UID's or GID's.  There is no need to populate this data for ALL users and groups, just the ones that will be logging into linux.

This samba config syntax is valid for Samba >3.0.25.  I have not tested it on any of the 3.3 or 3.4 releases.

First step, resolv.conf and hosts.  You need to be able to fully qualify your hostname against the AD domain name.  You also need to have the AD servers setup as your DNS servers.

dig testdomain.net SOA - I always make this the primary nameserver

dig testdomain.net NS - For the other 2

/etc/resolv.conf

```
search TESTDOMAIN.net

domain TESTDOMAIN.net

nameserver 10.10.10.22

nameserver 10.10.10.23
```

/etc/hosts

```
127.0.0.1               localhost

10.10.11.22            linuxbox linuxbox.TESTDOMAIN.net
```

Next I setup the smb.conf.  The main thing to look out for here are the idmap sections.

*you might try setting "winbind use default domain = yes" and then trying out the GSSAPI features of http://rc.quest.com/topics/putty/ - I prefer to leave it as default

/etc/samba/smb.conf

```
[global]

        workgroup = CITRITE

        realm = CITRITE.NET

        server string = Samba file and print server

        security = ADS

        log level = 3

        max log size = 4192

        printcap name = cups

        preferred master = No

        idmap domains = CITRITE

        idmap backend = tdb

        idmap alloc backend = tdb

        idmap cache time = 1800

        winbind separator = +

        winbind enum users = Yes

        winbind enum groups = Yes

        winbind nss info = rfc2307

        winbind refresh tickets = Yes

        winbind normalize names = Yes

        idmap config CITRITE:default = yes

        idmap config CITRITE:schema_mode = rfc2307

        idmap config CITRITE:backend = ad

        idmap config CITRITE:range = 10000-999999

        idmap config CITRITEN:cache time = 1800

        idmap alloc config:range = 5000 - 9999

[homes]

        comment = Home Directories

        valid users = %S, %D%w%S

        read only = No

[printers]

        comment = All Printers

        guest ok = Yes

        printable = Yes

        browseable = No

        available = No
```

Make sure that any and all references to your AD domain name in the krb5.conf are in UPPER case!

/etc/krb5.conf		

```
[logging]

 default = FILE:/var/log/krb5libs.log

 kdc = FILE:/var/log/krb5kdc.log

 admin_server = FILE:/var/log/kadmind.log

[libdefaults]

 default_realm = TESTDOMAIN.NET

 dns_lookup_realm = true

 dns_lookup_kdc = true

 ticket_lifetime = 36000

 forwardable = yes

[realms]

 TESTDOMAIN.NET = {

  kdc = *

  kdc = TESTDOMAIN.NET

  default_domain = TESTDOMAIN.NET

  kdc = TESTDOMAIN.NET

 }

[domain_realm]

 .TESTDOMAIN.net = TESTDOMAIN.NET

 TESTDOMAIN.net = TESTDOMAIN.NET

[appdefaults]

 pam = {

   debug = false

   ticket_lifetime = 36000

   renew_lifetime = 36000

   forwardable = true

   krb4_convert = false

 }
```

Now, startup winbind and samba.  Go throught the logs and make sure that there are no errors.  If you find no errors, go ahead and join the domain using an AD account with privelages to add computers to the domain of course.

```
net ads join -U msalerno
```

nsswitch.conf and pam updates to follow, I just need to document them.

# MISC Command for validating/troubleshooting domain membership and uid/gid mappings

# -P can be replace by -U <domainusername> with and "net" commandnet ads testjoin -P

net ads lookup

net ads search '(|(uidNumber=*)(gidNumber=*))' objectCategory sAMAccountName uidNumber gidNumber -P

Long: net ads status -P

Short: net ads info

wbinfo -t

wbinfo -u

wbinfo -g

getent passwd TESTDOMAIN+msalerno

getent passwd 20045

getent group TESTDOMAIN+unixusers

getent group 20000

# Purging logs and idmap cache

rm -f /var/cache/samba/winbindd_*

rm -f /var/cache/samba/idmap_cache.tdb

rm -f /var/log/samba/*

/etc/ini.d/samba restart && /etc/init.d/winbind restart

# Deleting winbind machine sid (local) and clearing logs - Requires re-join

rm -f /var/log/samba/*.tdb && rm -f /etc/samba/*tdb && rm -f /var/cache/samba/* && 

rm -f /var/log/samba/*

/etc/ini.d/samba restart && /etc/init.d/winbind restart

----------

## ShineOn

I know this is an old topic, but things have changed.

Starting with Samba 3.3, the idmap functionality for idmap_ad with rfc2307 no longer uses gidNumber, even though gidNumber is the rfc2307 primary group attribute.

For some reason, they chose to ignore rfc2307 just for the primary gid - they still use uidNumber, unixHomeDirectory for home directory and loginShell for the login shell.

Now, they default to use the Active Directory proprietary attribute primaryGroupID, which always defaults on user object creation to "513" which is the Windows "Domain Users" group.  To get the gid of the primaryGroupID they have to do a second lookup of the group identified by the primaryGroupID, to find the gidNumber of that group object.

I have no idea what the general repercussions of reassigning the primaryGroupID to another group object would be.

I am as yet unaware of a way to force idmap_ad with rfc2307 to force use of the user objects' gidNumber value.  If the Samba team is looking for something constructive to do, that would be my suggestion - add an option to make idmap_ad with rfc2307 behave the way it is supposed to, and use the gidNumber instead of the proprietary AD primaryGroupID with its secondary lookup to find gidNumber.

So, if you had older Samba with idmap_ad and rfc2307 integration working perfectly, don't upgrade to any Samba 3.30 or later or you will have to make major changes to how your groups are assigned.  If you have been using extended ACL support to assign POSIX permissions based on the primary gid you had populated in the rfc2307 gidNumber attribute, you will have to deal with that as well.

----------

