Using WinBind

(I was at this before, see , with limited success.) But this time, we have a much cleaner environment, with a sensible domain name, the name servers agreeing with the AD servers, and a brand new Ubuntu Lucid free of cruft.

Using WinBind takes a bit of configuring. It is also the best way to start understanding what is required to make Linux authenticate against AD. The Ubuntu AD HOWTO describes nicely what steps are required. The document Winbind: Use of Domain Accounts describes details of WinBind-specific configuration.

And there's also a Wiki entry on WinBind configuration, not to be confused with this Wiki entry on non-WinBind authentication against AD.

  1. apprentice@testbox:~$ sudo apt-get install winbind

    [Note]Note

    WinBind and nscd do not mix well.

  2. WinBindd (the daemon) is configured through smb.conf.

    In /etc/samba/smb.conf:

      [global]
      workgroup = MYWG
      server string = Samba Client Version %v
    
      security = ADS
      realm = MYWG.DOMAIN.COM
      password server = mywg.domain.com
    
      encrypt passwords = yes
      log level = 3
      log file = /var/log/samba/%U.log
      max log size = 50
      template shell = /bin/bash
      template homedir = /home/%D/%U 
      winbind use default domain = yes
      winbind enum groups = no
      winbind enum users = no
    
      idmap backend = tdb 1
      idmap config MYWG : backend  = ad 2
      idmap config MYWG : range = 65536-999999999
      idmap config MYWG : schema_mode = rfc2307
      winbind nss info = template rfc2307
      winbind cache time = 3600
    
      wins server =        mywg.domain.com:192.168.32.1 \
      adsv01.mywg.domain.com:192.168.32.3 \
      adsv02.mywg.domain.com:192.168.32.1 \
      adsv03.mywg.domain.com:192.168.32.2 \
      adsv04.mywg.domain.com:192.168.32.4
      winbind refresh tickets = true
    	  

    1

    There is a separate page on idmap configuration.

    2

    Ubuntu Precise as of this writing has Samba 3.4.7, and setting this to ad works, whether AD is serving UIDs or not. But Debian Sid has Samba 3.6.4, and with that, ad here breaks winbind when AD is not serving UIDs (through it's UNIX attributes).

  3. In /etc/nsswitch.conf:

      passwd:         files winbind
      group:          files winbind
      shadow:         files
    
      hosts:          files dns wins
      networks:       files wins
    
      protocols:      db files
      services:       db files
      ethers:         db files
      rpc:            db files wins
    
      netgroup:       wins
    	  

  4. With a TXT record for _kerberos in the name server, we could've done without any Kerberos config. But we don't have such a record, so in /etc/krb5.conf we put:

      [libdefaults]
      default_realm = MYWG.DOMAIN.COM 1
    
      # The following krb5.conf variables are only for MIT Kerberos.
      krb4_config = /etc/krb.conf
      krb4_realms = /etc/krb.realms
      kdc_timesync = 1
      ccache_type = 4
      forwardable = true
      proxiable = true
    
      # The following libdefaults parameters are only for Heimdal Kerberos.
      v4_instance_resolve = false
      v4_name_convert = {
      host = {
      rcmd = host
      ftp = ftp
      }
      plain = {
      something = something-else
      }
      }
      fcc-mit-ticketflags = true
    
      [realms]
    
      [domain_realm]
    
      [login]
      krb4_convert = true
      krb4_get_tickets = false
    	  

    1

    This line is all that has changed compared to the default krb5.conf, and even it was done through debconf. If you answered debconf when installing e.g. heimdal-clients, you shouldn't even have to touch the file.

  5. (And refitting library config for nsswitch.)

    apprentice@testbox:~$ sudo ldconfig -v |grep winbind
    apprentice@testbox:~$ sudo /etc/init.d/winbind restart

  6. Now, the machine needs to be joined to the domain. That means: an entry in the AD LDAP tree needs to be created for the machine that is joining the domain, and it needs to be given a Kerberos principal. For this, you need an account on the AD server with appropriate rights to do such things.

    apprentice@testbox:~$ sudo net ADS JOIN -U AdminUser%VerySecretPasswd createupn=host/$(hostname -f)@MYWG.DOMAIN.COM createcomputer="OU=Computers,OU=DOMAIN,DC=mywg,DC=domain,DC=com"
    Failed to join domain: failed to precreate account in ou OU=Computers,OU=DOMAIN,DC=mywg,DC=domain,DC=com: Constraint violation
    apprentice@testbox:~$ sudo net ads testjoin
    Join is OK

    ... so the join succeeded anyway.

As a result of this, we can now log in using AD credentials, and say e.g.:

aduser@testbox:~$ net ads printer search
Ignoring unknown parameter "refresh tickets"
create_local_private_krb5_conf_for_domain: smb_mkstemp failed, for file /var/run/samba/smb_tmp_krb5.V3ykII. Errno Permission denied
Ignoring unknown parameter "refresh tickets"
create_local_private_krb5_conf_for_domain: smb_mkstemp failed, for file /var/run/samba/smb_tmp_krb5.7BwUIx. Errno Permission denied
objectClass: top
objectClass: leaf
objectClass: connectionPoint
objectClass: printQueue
serverName: dre01.mywg.domain.com
driverName: PS Driver for Universal Print
printerName: FY_Students
<snip more printers>