tengel/papyri
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
papyri/md/active_directory_with_winbind.md
tengel e8fb7b288e initial import
2024-03-20 11:40:22 -05:00

9.4 KiB
Raw Blame History

Active Directory with Winbind

Contents

Prerequisites

AD Setup Information

Needed information:

  • NETBIOS name of one or more domain controllers
  • DNS IPs of same servers that resolve lookups
  • Admin level user already in the AD

Examples used in this article:

  • AD1.DOMAIN.LOCAL, AD2.DOMAIN.LOCAL
  • 192.168.100.10, 192.168.100.20
  • 'admin'

Implementation

Install RPMs

Standard YUM install:

RHEL6:
# yum install samba-winbind samba-winbind-clients krb5-workstation krb5-libs

RHEL5:
# yum install samba3x-winbind samba3x-client krb5-workstation krb5-libs

Notes:

  • krb5-workstation adds /usr/kerberos/bin to your $PATH, you may need to log in again so that kinit and other apps are now found
  • RHEL5 winbind is not Windows 2008R2+ friendly. Use winbind3x (samba3x) RPMs instead

DNS Configuration

/etc/resolv.conf

nameserver 192.168.100.10
nameserver 192.168.100.20
search DOMAIN.LOCAL

Configure Kerberos

/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 = DOMAIN.LOCAL
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 24h
  forwardable = yes

 [realms]
  DOMAIN.LOCAL = {
   kdc = AD1.DOMAIN.LOCAL:88
   kdc = AD2.DOMAIN.LOCAL:88
   admin_server = AD1.DOMAIN.LOCAL:749
   admin_server = AD2.DOMAIN.LOCAL:749
  }

 [domain_realm]
  .DOMAIN.local = DOMAIN.LOCAL
  DOMAIN.local = DOMAIN.LOCAL

 [appdefaults]
  pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
  }

Get a Kerberos ticket

# kinit admin@DOMAIN.LOCAL

List the ticket provided

# klist

Destroy the ticket

# kdestroy

Samba Configuration

/etc/samba/smb.conf

[global]
  workgroup = DOMAIN
  interfaces = 127.0.0.1 eth0
  bind interfaces only = true
  security = ads
  passdb backend = tdbsam
  template shell = /bin/bash
  template homedir = /home/%D/%U
  realm = DOMAIN.LOCAL
  password server = AD1.DOMAIN.LOCAL, AD2.DOMAIN.LOCAL
  winbind use default domain = yes
  winbind enum users = yes
  winbind enum groups = yes
  winbind refresh tickets = yes
  idmap uid = 16777216-33554431
  idmap gid = 16777216-33554431
  printing = cups
  printcap name = cups
  load printers = no

If required you can assign a name to the server. This is useful since NT has a limit of 15 chars to the servers. Just add:

netbios name = MYNTNAME

Join the domain

# net ads join -U admin

Example session:

# net ads join -U admin
 Enter admin's password:
 Using short domain name -- DOMAIN
 Joined 'MYSERVER' to realm 'domain.local'
 [2012/03/04 06:06:06.123456,  0] libads/kerberos.c:333(ads_kinit_password)
   kerberos_kinit_password MYSERVER$@DOMAIN.LOCAL failed: Client not found in Kerberos database
 DNS update failed!

This error message is expected, the server joined the domain, but the AD DNS was not updated for your server.

Configure winbind authentication

# authconfig-tui
  1. Select Use Winbind under the User Information section
  2. Select Use MD5 Passwords under the Authentication section
  3. Select Use Shadow Passwords under the Authentication section
  4. Select Use Winbind Authentication under the Authentication section
  5. Select Local Authentication is sufficient under the Authentication section
  6. Click Next
  7. Click OK (not Join Domain!)

PAM Configuration

The system may need to be updated to make two configuration changes; it's possible one or both of these are already taken care of however. The first change is to update the existing line for pam_winbind.so and add extra config; the second is to add/update the pam_mkhomedir.so line to have the user's home directory create itself.

Whenever editing PAM config files, ALWAYS test logins in a second terminal before you log out of the editing session. Breaking a PAM config file can cause root to be locked out and require single-user mode to rescue.

RHEL5 and RHEL6

This is a pseudo diff of the changes to be made; examine the existing file and apply only the needed values as shown.

/etc/pam.d/system-auth

< auth        sufficient    pam_winbind.so use_first_pass
---
> auth        sufficient    pam_winbind.so krb5_auth krb5_ccache_type=FILE use_first_pass

> session     required      pam_mkhomedir.so skel=/etc/skel umask=0022

RHEL6 Only

Configure

In RHEL5/CentOS5 all the various other PAM configuration files sub-include system-auth; in RHEL6 this was split out into two different files; some sub-include system-auth (like sudo), some sub-include password-auth (like sshd). Changing both files is required.

/etc/pam.d/password-auth

make the exact same changes as outlined above

Parent Home Directory

All DOMAIN homedirs will be created below this dir by pam_mkhomedir.so (via smb.conf template homedir variable):

# mkdir /home/DOMAIN
# chcon --reference=/home /home/DOMAIN

Testing

Test the basics:

# wbinfo -u
# wbinfo -g
# ssh DOMAIN\\admin@localhost

Due to an interesting conflict between the presence of local user 'admin' in /etc/passwd (with /home/admin defined) and the attempt to use /home/DOMAIN/admin during a DOMAIN login you can get curious permission denied results. It's best to test DOMAIN logins with a username other than one that exists in /etc/passwd on the local machine to avoid the DOMAIN login conflict with pam_mkhomedir.

Cached Logins

The pam_winbind.so module supports cached logins - this can be handy if the Active Directory server(s) become unavailable, you'll still be able to log into Linux. It is very useful to include a cache time otherwise the cache seems not to be updated regardless of the default value(300 secs). This parameter specifies the number of seconds the winbindd will cache user and group information before querying an AD server again.

In the same global section as defined above, add a new directive as shown:

/etc/samba/smb.conf

[global]
  ...
  winbind offline logon = yes
  winbind cache time = 600
  ...

It's possible that this file may not exist; create it if needed:

/etc/security/pam_winbind.conf

[global]
 cached_login = yes

Perform a standard Winbind restart and test things out:

# service winbind restart
# smbcontrol winbind offline

# wbinfo --online-status
 BUILTIN : online
 MYSERVER : online
 DOMAIN : offline

# ssh DOMAIN\\username@localhost
 Domain Controller unreachable, using cached credentials instead. Network resources may be unavailable
 ...

# smbcontrol winbind online

Some items - such as groups - don't get added to the cache until there is a successful login when things are in online mode; this may affect tools like sudo or sshd if they are configured to allow/restrict access based on group level membership. Your exact situation will determine any further tweaks needed to fully support offline access in an emergency. This can be fixed with the use of winbind cache time as noted above. If required, the cache can be deleted by removing the /var/lib/samba/*.tdb files.

User crontabs

There is a problem with the vixie-cron (RHEL5) and cronie <= 1.4.7 (RHEL6) packages and crontabs which belong to remote network users; when CROND starts up at boot it cannot "see" these remote users when scanning the /var/spool/cron/ crontabs as networking is not online yet; as a consequence it places each unmatched crontab in an "Orphan" list and never checks again. Restarting CROND after Winbind/LDAP/NIS/etc. are up will work correctly, so one possible solution if this is needed is to place a 'service crond restart' in /etc/rc.d/rc.local if you must use this type of crontab.

This issue was fixed in 1.4.8 release of cronie; if it is not yet available any RPM upgrade will have to be manually rebuilt from the Koji system (Fedora packaging) to obtain a newer release.

The cronie package in RHEL6 replaces the vixie-cron and anacron packages from RHEL5. Compiling (rebuilding) cronie for RHEL5 and doing a manual package swap may work but is untested. It would be best to create a local user account to run the crontabs instead of using a remote network user until (and if) Red Hat releases packages which address this issue.

References