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:

   [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:

   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:

   [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:

   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:

   /etc/init.d/samba start

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

   Code:

   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:

   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:

   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:

   #%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:

   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:

   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 :

[smadasam]

when I execute