OpenBSD Domain Authentication

• Adopted from: http://serverfault.com/questions/20202/authenticating-openbsd-against-active-directory

• Users must exist on the OpenBSD system before attempting to login. They are not autocreated.
• If you want users autocreated, look into Samba/Winbind. I've had nothing but trouble (inexplicable crashes, serious log spamming, unreliable authentication) from it, so I only use it when I have to.
• This was tested on OpenBSD 4.5 and Windows Server 2003. I'm pretty sure it'll work with Win2k, but YMMV.
• This version of OpenBSD uses Heimdal 0.7.2. Everything here aside from the paths and login.conf stuff will probably work on other *nixes running the same Heimdal, but again, YMMV.

These steps assume you are trying to authenticate myuser@puffer.jibcnet.ca against the domain EXAMPLE.CA. The domain controller is kdc.EXAMPLE.CA. The OpenBSD host that will be doing authentication request is puffer.example.ca

• Create an Active Directory User account named puffer(that's not a typo, these instructions won't work with a Computer account). Disable password expiration and don't let the user change its own password. Set the password to whatever you like - it'll be changed soon.
• It's probably a good idea to create the User account under a new OU, remove it from the Domain Users group and add it to a dedicated group. This is all a matter of taste and your security layout.
• On kdc.EXAMPLE.CA, download and install Windows Server Support Tools (specifically, you'll need ktpass.exe)
• On kdc.EXAMPLE.CA, run:
  • ktpass -out c:\tmp\puffer.keytab -princ host/puffer.example.ca@EXAMPLE.CA -mapuser puffer -pType KRB5_NT_PRINCIPAL +rndpass
  • sample output

    U:\>ktpass -out c:\tmp\puffer.keytab -princ host/puffer.example.ca@EXAMPLE.CA -mapuser puffer -pType KRB5_NT_PRINCIPAL +rndpass
    Targeting domain controller: kerberos.EXAMPLE.CA
    Using legacy password setting method
    Successfully mapped host/puffer.example.ca to puffer.
    Key created.
    Output keytab to c:\tmp\puffer.keytab:
    Keytab version: 0x502
    keysize 68 host/puffer.example.ca@EXAMPLE.CA ptype 1 (KRB5_NT_PRINCIPAL) vno 4 e
    type 0x17 (RC4-HMAC) keylength 16 (0xe079da35bcf56b0524331d2f6da746f5)

  • This updates the puffer user's password to something random (+rndpass), maps the Kerberos principal "host/puffer.example.ca@EXAMPLE.CA" to the user "puffer" in Active Directory, and then dumps the principal and private key info into the -out keytab file.
• Securely copy c:\temp\myhost.keytab to myhost and delete the file from pdc.EXAMPLE.COM

• On puffer, add the AD keytab to your main keytab:
  • ktutil copy /etc/puffer.keytab /etc/kerberosV/krb5.keytab
• Configure /etc/kerberosV/krb5.conf. Below is the bare minimum that you need. There's a lot of options available, take a look at the manpage for more details. This just sets the maximum acceptable clock skew to 5 minutes, makes JIBCNET.CA the default realm, and tells Kerberos how to translate between DNS and Kerberos realms.

  • [libdefaults]
            # Set the realm of this host here
            default_realm = EXAMPLE.CA
    
            # Maximum allowed time difference between KDC and this host
            clockskew = 300
    
            # Uncomment this if you run NAT on the client side of kauth.
            # This may be considered a security issue though.
            # no-addresses = yes
    
    [realms]
             EXAMPLE.CA = {
    
                    default_domain = example.ca
    
                    # Specify KDC here
                    kdc = kerberos.example.ca
    
                    # Administration server, used for creating users etc.
                    admin_server = kerberos.example.ca
            }
    
            # Example of a "foreign" realm
            OTHER.REALM = {
                    kdc = kerberos.other.domain
                    default_domain = other.domain
                    v4_domains = other.domain
            }
    
    # This sections describes how to figure out a realm given a DNS name
    [domain_realm]
            .example.ca = EXAMPLE.CA
    
    
    [kadmin]
            # This is the trickiest part of a Kerberos installation. See the
            # heimdal infopage for more information about encryption types.
    
            # For a k5 only realm, this will be fine
            # default_keys = v5
    
    [logging]
            # The KDC logs by default, but it's nice to have a kadmind log as well.
            kadmind = FILE:/var/heimdal/kadmind.log
    
    

• Verify that you can get a ticket:

  • $ kinit admin@EXAMPLE.CA
    admin@EXAMPLE.CA's Password:
    $ klist
    Credentials cache: FILE:/tmp/krb5cc_1000
            Principal: admin@EXAMPLE.CA
    
      Issued           Expires          Principal
    Sep  4 11:50:58  Sep  4 21:48:12  krbtgt/EXAMPLE.CA@EXAMPLE.CA
    $
    

• Modify /etc/login.conf to use Kerberos authentication. Your exact login.conf configuration will vary depending on how you use your system, but to go from a vanilla install to using Kerberos, just edit and comment this line under the default login class:

  •           :tc=auth-defaults:\
    
          And add above it:
    
              :auth=krb5-or-pwd:\
    
          Like this:
    
    default:\
            :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin:\
            :umask=022:\
            :datasize-max=512M:\
            :datasize-cur=512M:\
            :maxproc-max=128:\
            :maxproc-cur=64:\
            :openfiles-cur=128:\
            :stacksize-cur=4M:\
            :localcipher=blowfish,6:\
            :ypcipher=old:\
            :auth=krb5-or-pwd:\
            :tc=auth-defaults:\
            :tc=auth-ftp-defaults:
    

    • This checks Kerberos first unless the user is root. If Kerberos fails, it will use local passwords.
• Add the users you'd like to authenticate on this host. Leave the passwords blank unless you want them to be able to use both Active Directory and local passwords (not recommended).
  • You can blank existing users' passwords "chpass <user>" and replacing the "Encrypted password:" value with an asterisk (*)
  • Try loging in into the system via SSH and domain account
  • Test SSH and Sudo. Both should work flawlessly with your Active Directory credentials.

• A couple useful sites:
  • http://technet.microsoft.com/en-us/library/bb742433.aspx
  • IBM Docs

« home | openbsd