View previous topic :: View next topic |
Author |
Message |
msalerno Veteran
Joined: 17 Dec 2002 Posts: 1338 Location: Sweating in South Florida
|
Posted: Wed Oct 14, 2009 4:48 pm Post subject: HowTo: Samba and AD auth via rfc2307 and idmap_ad |
|
|
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
Code: | search TESTDOMAIN.net
domain TESTDOMAIN.net
nameserver 10.10.10.22
nameserver 10.10.10.23 |
/etc/hosts
Code: | 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
Code: | [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
Code: | [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.
Code: | 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 |
|
Back to top |
|
|
ShineOn n00b
Joined: 24 Feb 2011 Posts: 1 Location: Wisconsin
|
Posted: Thu Feb 24, 2011 9:34 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|