Winbind w/ consistent UIDs/GIDs and NO LDAP/SFU/AD4Unix

[xunil]

This procedure will allow you to configure Linux installations to authenticate against an Active Directory w/o requiring an LDAP server to host UNIX user information nor installing Service for Unix or AD4Unix to host the information in AD. It has the added benefit of keeping UIDs and GIDs consistent across multiple installations and across reboots by using the idmap_rid Samba plugin.

There is one caveat: this method does not work in multiple domain environments, so the "allow trusted domains" Samba option must be set to no.

This guide assumes you already have an AD installed and configured w/ some users in it. I performed these steps against Windows 2000 Server SP4 w/ AD in mixed mode; I don't know if it will work against any Windows 2003 versions or if it will work in native mode. You will need to know the following information before beginning:

• The AD's realm AKA name eg. mycompany.com
• The AD's short name AKA legacy domain name eg. MYCOMPANY
• The hostname or IP address of the AD (any primary will do)
• The username for a user that can add computer accounts (usually the Administrator account) and the user's password

1. Merge Samba w/ the winbind, ldap, and kerberos USE keys on. ldap and kerberos are necessary for the Samba ebuild to include AD support.
2. Configure the Kerberos libraries for the AD by editing /etc/krb5.conf:

   Code: Select all

   [libdefaults]
           ticket_lifetime = 600
           default_realm = <AD realm>
           dns_lookup_realm = false
           dns_lookup_kdc = false
   
   [realms]
           <AD realm> = {
           kdc = <hostname or IP of AD primary>
           }
   
   [domain_realm]
           .<domain> = <AD realm>
           <domain> = <AD realm>
   
   [kdc]
           profile = /etc/krb5kdc/kdc.conf
   
   [logging]
           kdc = FILE:/var/log/krb5kdc.log
           admin_server = FILE:/var/log/kadmin.log
           default = FILE:/var/log/krb5lib.log
   

   Make sure you use all capital letters when specifying the AD realm. The <domain> options I've found to not really matter, so anything sensible like your domain name will be fine. You can test that things are working by issuing the following command:

   Code: Select all

   kinit <AD username>@<AD realm>

   Make sure to use capital letters when specifying the AD realm. The command will ask for the user's password; if it doesn't print anything else after you enter your password, Kerberos is working.
3. Configure Samba by editing /etc/samba/smb.conf:

   Code: Select all

   [global]
           realm = <AD realm>
           security = ADS
           encrypt passwords = yes
           password server = <hostname or IP of AD primary>
           workgroup = <AD short name>
           allow trusted domains = no
           idmap backend = idmap_rid:<AD short name>=10000-50000
           idmap uid = 10000-50000
           idmap gid = 10000-50000
           template shell = /bin/bash
           winbind use default domain = yes
   

   If you adjust the UID and GID mapping ranges, I suggest keeping 10000 as the lower bound because it's likely local UIDs and GIDs will start to conflict below 10000. Also remember that the nobody user and group have the UID and GID of 65534.
4. Join the AD:

   Code: Select all

   net ads join -U <user who can add computer accounts eg. Administrator>

   The command will ask for the user's password, and after you enter that the command will indicate that the computer has joined.
5. Edit /etc/conf.d/samba and add winbind to the daemon list at the top. Start Samba:

   Code: Select all

   /etc/init.d/samba start

   Test Winbind to make sure it can fetch users and groups from the AD:

   Code: Select all

   wbinfo -u
   wbinfo -g
   

6. Edit /etc/nsswitch.conf to tell NSS to use Winbind to look up user information. Change only the passwd, shadow, and group lines!

   Code: Select all

   passwd:    files winbind
   shadow:    files
   group:       files winbind
   

   Winbind doesn't provide shadow information; we'll use PAM for authentication later. Test the changes:

   Code: Select all

   getent passwd
   getent group
   

   You should see your AD users and groups.
7. Edit /etc/pam.d/system-auth to configure PAM to use Winbind for authentication. Here is a "stock" system-auth file w/ the changes (there are only two, in the auth and account sections):

   Code: Select all

   #%PAM-1.0
   
   auth       required     pam_env.so
   auth       sufficient    pam_winbind.so
   auth       sufficient    pam_unix.so likeauth nullok
   auth       required     pam_deny.so
   
   account    sufficient  pam_winbind.so
   account    required   pam_unix.so
   
   password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
   password   sufficient    pam_unix.so nullok md5 shadow use_authtok
   password   required     pam_deny.so
   
   session    required   pam_limits.so
   session    required   pam_unix.so
   

   You can test this with su:

   Code: Select all

   su - <domain user>

   If you get a warning about the user's home directory being missing, that's fine.
8. Try SSHing in to the Linux computer. If you created a home directory for the user, try logging in and starting X.
9. If everything's working, set up Samba to start during the boot sequence:

   Code: Select all

   rc-update add samba default

FAQ

• Q. How do I deal w/ groups that have spaces in their names?
  A. Either escape the space ("\ " w/o the quotes) or quote the group's name. The former works for the sudoers file, and the latter works many other places including in the shell. Some applications can't deal w/ spaces in group names at all, so you'll need to find a workaround.
• Q. How do I restrict access to Linux computers when using this method?
  A. Use PAM's access module. Read /etc/security/access.conf.
• Q. AD doesn't create a group for every user, and I need this functionality!
  A. There are two workarounds:
  1. Don't bother. Default everyone's umask so that they don't create files w/ group read permission.
  2. Create a group for every user by creating a group w/ the same name as the user but with a g appended to the end eg. user: xunil, group: xunilg. AD can't create groups with the same names as users.
• Q. How do I automatically create home directories for AD users?
  A. The mkhomedir PAM module can do this, but IIRC it requires that processes run as root for it to work. I don't recommend it. Instead, use a network file system like NFS to share home directories or provide a SUID command or script that users can run to create their home directories for themselves.

[giant]

Hi Xunil,

nice howto

I went through all the steps and it's working now.

You might want to add to point 5 the daemon line from the /etc/conf.d/samba file like this :

daemon_list="smdb nmdb winbind"

Cheers !

[smadasam]

when I execute

Code: Select all

net ads join "OU" -U valid.username

I get

Code: Select all

[2006/05/08 15:46:56, 0] param/loadparm.c:map_parameter(2641)
  Unknown parameter encountered: "realm"
[2006/05/08 15:46:56, 0] param/loadparm.c:lp_do_parameter(3386)
  Ignoring unknown parameter "realm"
ADS support not compiled in

The error seems to point to not havin ADS compiled in obviously, but in my package.use I have

Code: Select all

net-fs/samba acl ldap kerberos pam winbind
net-nds/openldap sasl samba kerberos
dev-libs/cyrus-sasl authdaemond -java kerberos pam ldap

It would seem that if I had ldap and kerberos use flags, it should be able to do AD. Any ideas?