Authenticating UNIX/Linux to Windows 2008R2. Part 2 : Solaris 10

Background

Continuation of setting up LDAP/Kerberos clients to use Windows 2008R2 Server as the “source of truth”.

See the previous blog , for the steps for how Windows was set up.

Installation of Solaris

    1. Create a Solaris 10 x64 VM, with the following configuration:
      1. Custom Config, VMware Workstation 6.5 compatible
      2. I will install the operating system later.
      3. Guest OS : Sun Solaris, Solaris 10 64-bit
      4. VM Name: “sol10host1”
      5. 1 Processor, 1 Core per Processor
      6. 1024MB Memory
      7. Use Host-Only Networking
      8. IDE Controller type: ATAPI
      9. SCSI Controller type: LSI Logic
      10. Disk: Create a new virtual disk, SCSI, Maximum Disk size, 10GB, Store as Single File, sol10host1.vmdk (on an NTFS filesystem).
      11. Insert the Solaris installer CD (Solaris 10 Update 9),
      12. Power on and Boot from CD.
    2. Install Solaris 10 with the following options:
      1. Select Option 4, Solaris Interactive Text (Console Session)
      2. Keyboard:  US-English
      3. Language: English
      4. Networked: Yes
      5. Use DHCP: No
      6. Hostname: sol10host1.example.com
      7. IPv4 address: 192.168.102.20
      8. Subnet Netmask: 255.255.255.0
      9. IPv6: No
      10. Default route: None
      11. Kerberos: Yes
      12. Default Realm: EXAMPLE.COM
      13. Administration Server: adserver.example.com
      14. First KDC : adserver.example.com
      15. Name Service : DNS
      16. Domain Name: example.com
      17. Server IP Address: 192.168.102.10
      18. Search Domains: none
      19. NFSv4: Use NFSv4 name derived from system
      20. TimeZone: Australia/Victoria
      21. Date/Time: Correct
      22. Remote Services: Enabled
      23. Registration with Oracle: No
      24. Proxy configuration: none
      25. Installation Method: Standard
    3. Standard Installation:
      1. Eject CD
      2. Automatically Reboot
      3. Accept License
      4. Locale : Australasia
      5. Initial Locale: POSIX C
      6. No addtional software sources
      7. Use ZFS for the root filesystem
      8. Select Entire Distribution (5867MB)
      9. Install onto c1t0d0
      10. Use all the defaults for ZFS pool names etc
    4. Install VMware Tools:
# cd /tmp
# gzip -d < /cdrom/cdrom0/vmware-solaris-tools.tar.gz | tar xf -
# cd vmware-tools-distrib
# ./vmware-install.pl -d
# vmware-toolbox-cmd timesync enable
Enabled

Plan of attack (in order):

  1. Get ldapsearch working with simple bind, unencrypted
  2. Configure LDAP with ldapclient
  3. Verify LDAP works with getent(1M), id(1M), etc
  4. Export the Root CA cert from Windows to UNIX
  5. Check the CA cert works with OpenSSL
  6. Import the CA cert
  7. Get LDAPS working with ldapsearch
  8. Change ldapclient to use LDAPS rather than LDAP
  9. Verify Kerberos works: Initially, without a host principal (krb5.keytab)
  10. Configure PAM to use Kerberos (edit /etc/pam.conf)
  11. Verify that services like login can use kerberised IDs and that the password works
  12. Create a host principal keytab in Windows. Import it into UNIX.
  13. Verify that kinit -k works
  14. Edit /etc/krb5/krb5.conf to include “verify_ap_req_nofail = true” in the [libdefaults] section. This will secure the UNIX box to prove it is talking with the bonefide KDC.
  15. Get Single-Sign-On working

1. Ldapsearch, unencrypted

Using the simple bind user, verify that lookups can be done using unencrypted LDAP. Not only will this return a record, but will also give the correct attribute name:

# ldapsearch -v -h adserver -D "CN=ldapsearch,CN=Users,DC=example,DC=com" \
-b "DC=example,DC=com" -w ld@p53arch -s sub "cn=unix1"

ldapsearch: started Tue Aug  9 23:47:32 2011

ldap_init( adserver, 389 )
filter pattern: cn=unix1
returning: ALL
filter is: (cn=unix1)
version: 1
dn: CN=unix1,OU=UNIX,DC=example,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: unix1
givenName: unix1
distinguishedName: CN=unix1,OU=UNIX,DC=example,DC=com
instanceType: 4
whenCreated: 20110809102742.0Z
whenChanged: 20110809103818.0Z
displayName: unix1
uSNCreated: 20816
uSNChanged: 20823
name: unix1
objectGUID:: 8dUSWOctkEaf5x7FkpXrgw==
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 129573592626212649
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA9P+gsh3KJO48P5XaUAQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: unix1
sAMAccountType: 805306368
userPrincipalName: unix1@example.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com
dSCorePropagationData: 16010101000000.0Z
uid: unix1
msSFU30Name: unix1
msSFU30NisDomain: example
uidNumber: 10000 gidNumber: 10000
unixHomeDirectory: /home/unix1
loginShell: /bin/sh
Unfollowed continuation reference(s):
    ldap://ForestDnsZones.example.com/DC=ForestDnsZones,DC=example,DC=com
Unfollowed continuation reference(s):
    ldap://DomainDnsZones.example.com/DC=DomainDnsZones,DC=example,DC=com
Unfollowed continuation reference(s):
    ldap://example.com/CN=Configuration,DC=example,DC=com
1 matches

2. Configure LDAP with ldapclient, unencrypted

ldapclient(1M) is used to configure Solaris to use an LDAP search as the directory service to be used. This command is probably the hardest thing to get right for the unitiated. Why Solaris and Linux provide GUIs to change the simple options (eg Timezone), yet provide no GUI/TUI for this beats me.

The options will be written into the /var/ldap/ldap_client_file file

# cp /etc/nsswitch.dns /etc/nsswitch.conf
# cp /etc/nsswitch.ldap /etc/nsswitch.ldap.orig
# sed -e 's/^hosts:.*/hosts: files dns/' \
-e 's/^ipnodes:.*/ipnodes: files dns/' \
/etc/nsswitch.ldap.orig > /etc/nsswitch.ldap

# /usr/sbin/ldapclient manual \
-a profileName=simple \
-a authenticationMethod=simple \
-a credentialLevel=proxy \
-a proxyDN=CN=ldapsearch,CN=Users,DC=example,DC=com \
-a proxyPassword=ld@p53arch \
-a defaultSearchBase=DC=example,DC=com \
-a defaultSearchScope=sub \
-a defaultServerList=adserver \
-a domainName=example.com \
-a serviceSearchDescriptor=passwd:DC=example,DC=com?sub \
-a serviceSearchDescriptor=group:DC=example,DC=com?sub \
-a followReferrals=false
System successfully configured

FollowReferrals=false is required for LDAP. No idea why AD confuses LDAP here, but it won’t work without it.

We need to map the correct UNIX attributes, and type of objects to the LDAP attributes and LDAP objects. Not only must we tell LDAP  where to look (ie with the serviceSearchDescriptor), we must tell it what to look for (objectclass), and which attributes to use. For AD, these will do:

# /usr/sbin/ldapclient mod -a objectclassMap=passwd:posixAccount=user
System successfully configured
# /usr/sbin/ldapclient mod -a attributeMap=passwd:uid=sAMAccountName
System successfully configured
/usr/sbin/ldapclient mod -a attributeMap=passwd:uidnumber=uidNumber
System successfully configured
/usr/sbin/ldapclient mod -a attributeMap=passwd:gidnumber=gidNumber
System successfully configured
/usr/sbin/ldapclient mod -a attributeMap=passwd:gecos=cn
System successfully configured
/usr/sbin/ldapclient mod -a attributeMap=passwd:homedirectory=unixHomeDirectory
System successfully configured
/usr/sbin/ldapclient mod -a attributeMap=passwd:loginshell=loginShell
System successfully configured

# /usr/sbin/ldapclient mod -a objectclassMap=group:posixAccount=group
System successfully configured
/usr/sbin/ldapclient mod -a attributeMap=group:gidnumber=gidNumber
System successfully configured

At this stage, /etc/nsswitch.conf file will try to use LDAP for everything. It’s probably easiest if we just return the /etc/nsswitch.conf using dns, and change the right lines:

#  cp /etc/nsswitch.ldap.orig /etc/nsswitch.ldap
# sed -e 's/^passwd:.*/passwd: files ldap/' \
-e 's/^group:.*/group: files ldap/' \
/etc/nsswitch.dns > /etc/nsswitch.conf

Now we can test whether LDAP queries are working. Firstly, disable ldap:

# svcadm disable ldap/client

Manually start it with debugging options

# /usr/lib/ldap/ldap_cachemgr -d 6 -l /tmp/myfile

3. Verify getent(1M) works

Now, Lookups should work:

# getent group unixgrp1
unixgrp1::10000:
# getent passwd unix1
unix1:x:10000:10000:unix1:/home/unix1:/bin/sh

Now we can enable LDAP cachemgr:
# /usr/lib/ldap/ldap_cachemgr -K # svcadm enable ldap/client

4. Import the root CA Certificates

The .PEM format rootCA.cer file should be copied (probably with psftp.exe) to the Solaris system. For the purposes of this instruction it is saved in /rootCA.cer.

5. Verify that the certificate file is ok with OpenSSL

# /usr/sfw/bin/openssl x509 -in /rootCA.cer -subject -issuer -purpose
subject= /DC=com/DC=example/CN=example-ADSERVER-CA
issuer= /DC=com/DC=example/CN=example-ADSERVER-CA
Certificate purposes:
SSL client : Yes
SSL client CA : Yes
SSL server : Yes
SSL server CA : Yes
Netscape SSL server : No
Netscape SSL server CA : Yes
S/MIME signing : Yes
S/MIME signing CA : Yes
S/MIME encryption : No
S/MIME encryption CA : Yes
CRL signing : Yes
CRL signing CA : Yes
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : Yes
-----BEGIN CERTIFICATE-----
MIIDczCCAlugAwIBAgIQGGdCEtXMnZ9CxrbAG8zNEjANBgkqhkiG9w0BAQUFADBM
MRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHZXhhbXBsZTEc
MBoGA1UEAxMTZXhhbXBsZS1BRFNFUlZFUi1DQTAeFw0xMTA4MDkwOTI0NTBaFw0x
NjA4MDkwOTM0NDlaMEwxEzARBgoJkiaJk/IsZAEZFgNjb20xFzAVBgoJkiaJk/Is
ZAEZFgdleGFtcGxlMRwwGgYDVQQDExNleGFtcGxlLUFEU0VSVkVSLUNBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoeQeyJYdYiftNx0g2GOlDxWxo2ah
qsC5h7ryVEwr5BHv39aD33l+DZCHIKWRJA2DQk/xmyzElQhIAI1A7ikR9pPDegVP
eKNhl1n/I5KHrzWhJFCaMYcCmwf6H0X7HaYtDw2Ya2Qv9+s31yIXInA6b49vpXF/
/lkh8NeAh4lHCFBEOzLEaV9Oks6B+ZoSk47PWOFObbafIOY23keabekVn6DFekG5
h+WqihGaVjL7kpSJixyTDcY1WGAaBmiqPgVeCoNsMDIvdrflRIEO5yirQIGayzYN
IuW3HhiiuWkH48iwzcScKc0YMVTnRve5sJ6aQVEiUXvFaw8LDcX628upyQIDAQAB
o1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU3ijY
Of/XO1EuaGxon2AQGtZ1AGUwEAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEF
BQADggEBAD6Hy40U1CFMDRQ1lQxJsShFc1VqPION/49OYxM7NN07hLbC07VYwNdH
OpK0GvfAL8EExF5yX07NxTWZu1An8eZy1NzhSEdIsEo4wwMlej68DUuZaUK5azV9
EAPcVwQtWVqCowRNWR35VcSx8pYLxyCthNMj9uNjiGgXH7rgSf61JGRkzwnTEkUc
woi84vMGGVGqKNAqm0n0hlJgYGWmVKWfqs8GFwXP99VNTdNJqiJp4EmFiZyeZCRw
m7zKVvmPgQ7l9gq1zNBQ3E4eCj7gtvTKfJDk35uxk3IdOuWaKnDLrtHstb+SWkry
FIes6uSRw9XMupknrR3Og0MHXbx+UZU=
-----END CERTIFICATE-----

6. Import the Root CA Certificate

The certificate should be imported into /var/ldap:

# /usr/sfw/bin/certutil -A -n rootCA -t "CT,C,C" -d /var/ldap -i /rootCA.cer
# /usr/sfw/bin/certutil -L -d /var/ldap

Certificate Nickname                                         Trust Attributes
SSL,S/MIME,JAR/XPI

rootCA                                                       CT,C,C

There’s also a nasty little issue. The *.db files need to be readable by users, otherwise programs like id will fail if run by other than root if name-services-cachemgr isn’t running:

# chmod a+r /var/ldap/*.db

LDAPS can be tested that it is using the rootCA certificate as follows:

# /usr/sfw/bin/openssl s_client -connect adserver:636 -CAfile /rootCA.cer < /dev/null
CONNECTED(00000004)
depth=1 /DC=com/DC=example/CN=example-ADSERVER-CA
verify return:1
depth=0 /CN=adserver.example.com
verify return:1
---
Certificate chain
 0 s:/CN=adserver.example.com
   i:/DC=com/DC=example/CN=example-ADSERVER-CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF7jCCBNagAwIBAgIKEbgl6gAAAAAAAjANBgkqhkiG9w0BAQUFADBMMRMwEQYK
CZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHZXhhbXBsZTEcMBoGA1UE
AxMTZXhhbXBsZS1BRFNFUlZFUi1DQTAeFw0xMTA4MDkxNzAyMTRaFw0xMjA4MDgx
NzAyMTRaMB8xHTAbBgNVBAMTFGFkc2VydmVyLmV4YW1wbGUuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA16Aa3EZH2wW+6N0nWJ8oQvpsgha3AsBS
+iGuuMb9zMj+w5Ulj7tMO1EBQJNJ9Nmlk0kbjbs4+hLD+Jwknxzy4WXSN3yOVIpe
7f/2WJ2a35BXb0AHoMUrtk0UBNhBJgCN3ujxrmm5wWIIKIy9QhqMIFrP9O37XVdX
j6bWRB/5g3qIvpPdsrjizFcVuSx9fZ6apYwsE7E8sDV7IYHKZP7N12wKHXqgxVhQ
BTATusYvyfbLTDoNL/eg3kXcnmZefABhqjJh+Id9peAKTokhyC6KpYnmElm/4gzd
dJ2B4UIQfaL0iHUq5qB5i69jTR5hfQMJ6vHqDdG60e32Ga6oHYHeIwIDAQABo4IC
/TCCAvkwLwYJKwYBBAGCNxQCBCIeIABEAG8AbQBhAGkAbgBDAG8AbgB0AHIAbwBs
AGwAZQByMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAOBgNVHQ8BAf8E
BAMCBaAweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcN
AwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsG
CWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUMF1hyvrm
NUeMP6yIPklWxNlUEpQwHwYDVR0jBBgwFoAU3ijYOf/XO1EuaGxon2AQGtZ1AGUw
gdIGA1UdHwSByjCBxzCBxKCBwaCBvoaBu2xkYXA6Ly8vQ049ZXhhbXBsZS1BRFNF
UlZFUi1DQSxDTj1hZHNlcnZlcixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vy
dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1leGFtcGxlLERD
PWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9
Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgcUGCCsGAQUFBwEBBIG4MIG1MIGyBggrBgEF
BQcwAoaBpWxkYXA6Ly8vQ049ZXhhbXBsZS1BRFNFUlZFUi1DQSxDTj1BSUEsQ049
UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJh
dGlvbixEQz1leGFtcGxlLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0
Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBABgNVHREEOTA3oB8GCSsGAQQB
gjcZAaASBBDVqLtSbD/oR6YHGq+PNID0ghRhZHNlcnZlci5leGFtcGxlLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAQEAM7RqqBlu7t4fcqECr2wo4JxNhcvx3X/neTQwgGKA
s0ORxikhEw8/MofzzTOzcABx8mlG2XcjBjOjlTq3ezUqgVQB3SggqM8R3btlVCt0
1CYCKxb7g1w+IOyeU/LjXZhmk1lnPmysZgEkT1VfBx4xowHAmlZO48TcjhA/5+Fu
PcmeSXkGau20kFu11Y49aj5/sYGAK2WNgkDzCxo7vz/mSlyjEDFVT66NHVl3juVF
Y/Ymj0GPsW9Nh/3/y2VYKJFxVIPGEHSH9eSvtPUu++TgtNkxfKxPgjOu0vTIKisy
RR6i66q5Y+szSHxpXvW0StmvBZskbJmuSnQC6QdnSvoZVw==
-----END CERTIFICATE-----
subject=/CN=adserver.example.com
issuer=/DC=com/DC=example/CN=example-ADSERVER-CA
---
Acceptable client certificate CA names
/DC=com/DC=example/CN=example-ADSERVER-CA
/CN=adserver.example.com
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority
/CN=NT AUTHORITY
---
SSL handshake has read 2140 bytes and written 483 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: F13400000C163C401A27D1234CFAA4928A039239AD683D0E9ED2DE2E7D54C4F5
    Session-ID-ctx:
    Master-Key: 139F2855AE709F9D679BAB35DD122D5C3A383353A0A141B0A9FB9444766D8B744DEF68117E2C30A28365A682BA6A4A52
    Key-Arg   : None
    Start Time: 1313110928
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

7. Test ldapsearch works  with LDAPS

# ldapsearch -v -h adserver.example.com -p 636 -Z -P /var/ldap -D "cn=ldapsearch,cn=Users,dc=example,dc=com" -w ld@p53arch -b "dc=example,dc=com" "cn=unix1"
ldapsearch: started Wed Aug 10 13:42:37 2011

ldap_init( adserver.example.com, 636 )
filter pattern: cn=unix1
returning: ALL
filter is: (cn=unix1)
version: 1
dn: CN=unix1,OU=UNIX,DC=example,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: unix1
distinguishedName: CN=unix1,OU=UNIX,DC=example,DC=com
instanceType: 4
whenCreated: 20110809102742.0Z
whenChanged: 20110809135807.0Z
uSNCreated: 20816
uSNChanged: 20918
name: unix1
objectGUID:: 8dUSWOctkEaf5x7FkpXrgw==
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 129573592626212649
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA9P+gsh3KJO48P5XaUAQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: unix1
sAMAccountType: 805306368
userPrincipalName: unix1@example.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com
dSCorePropagationData: 16010101000000.0Z
uid: unix1
msSFU30Name: unix1
msSFU30NisDomain: example
uidNumber: 10000
gidNumber: 10000
unixHomeDirectory: /home/unix1
loginShell: /bin/sh
Unfollowed continuation reference(s):
ldaps://ForestDnsZones.example.com/DC=ForestDnsZones,DC=example,DC=com
Unfollowed continuation reference(s):
ldaps://DomainDnsZones.example.com/DC=DomainDnsZones,DC=example,DC=com
Unfollowed continuation reference(s):
ldaps://example.com/CN=Configuration,DC=example,DC=com
1 matches

NB. Fully qualified host names must be used, since those names are in ther certifcate. Short host names won’t work:

# ldapsearch -v -h adserver -p 636 -Z -P /var/ldap -D "cn=ldapsearch,cn=Users,>
ldapsearch: started Wed Aug 10 13:43:09 2011

ldap_init( adserver, 636 )
ldap_simple_bind: Can't contact LDAP server

8. Change ldapclient to use LDAPS rather than LDAP

We already know that LDAP works. We need to change the mechanism from simple to simple over TLS. Again we also must be careful to use the FQDN:

# /usr/sbin/ldapclient mod -a authenticationMethod=tls:simple
System successfully configured
# /usr/sbin/ldapclient mod -a defaultServerList=adserver.example.com
System successfully configured

We can verify that lookups are now working:

# getent passwd unix1
unix1:x:10000:10000:unix1:/home/unix1:/bin/sh
# id unix1
uid=10000(unix1) gid=10000(unixgrp1)

And moreover, a snoop of port 389 will show no unencrypted traffic being used.

9. Verify that Kerberos works

We can use a user’s ID and password to verify that kerberos works for user principals:

# kinit unix1@EXAMPLE.COM
Password for unix1@EXAMPLE.COM:
# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: unix1@EXAMPLE.COM

Valid starting                Expires                Service principal
08/10/11 14:06:08  08/11/11 00:06:10  krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 08/17/11 14:06:08, Etype(skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC

/etc/krb5/krb5.conf must be edited to specify the default realm. And “verify_ap_req_nofail = false” can be added to ignore missing host principals (/etc/krb5/krb5.keytab) until they have been set up.

# cat /etc/krb5/krb5.conf
[libdefaults]
default_realm = EXAMPLE.COM
verify_ap_req_nofail = false

[realms]
EXAMPLE.COM = {
kdc = adserver.example.com
admin_server = adserver.example.com
}

[domain_realm]
.example.com = EXAMPLE.COM example.com = EXAMPLE.COM

[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {

# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used# frequently.

period = 1d

# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
version = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}

Now for this to be useful, PAM must be configured to use kerberos

10. Configure PAM to use Kerberos

Edit /etc/pam.conf to add the pam_krb5.so.1 and pam_ldap.so.1 library files at these locations:

....
 login  auth requisite          pam_authtok_get.so.1
 login  auth required           pam_dhkeys.so.1
 login  auth required           pam_unix_cred.so.1
 login  auth sufficient       pam_krb5.so.1
 login  auth required           pam_unix_auth.so.1
 login  auth required           pam_dial_auth.so.1
 #
 other  auth requisite          pam_authtok_get.so.1
 other  auth required           pam_dhkeys.so.1
 other  auth required           pam_unix_cred.so.1
 other  auth sufficient       pam_krb5.so.1
 other  auth required           pam_unix_auth.so.1
....
 other  account requisite       pam_roles.so.1
 other  account sufficient      pam_ldap.so.1 other  account required        pam_unix_account.so.1
 #
 # Default definition for Session management
 # Used when service name is not explicitly mentioned for session management
....
 other  password required       pam_dhkeys.so.1
 other  password requisite      pam_authtok_get.so.1
 other  password requisite      pam_authtok_check.so.1
 other  password sufficient  pam_krb5.so.1
 other  password required       pam_authtok_store.so.1
....

11. Verifying Services

Before verifying services, create a home directory for the user:

# mkdir -m 700 /home/unix1
# chown unix1:unixgrp1 /home/unix1

Then check all the authentication methods (eg telnet, ssh, direct console, dtlogin)

Login:

sol10host1.example.com console login: unix1
Password:
Last login: Fri Aug 12 11:14:50 from 192.168.102.1
Oracle Corporation      SunOS 5.10      Generic Patch   January 2005
$ exit

Telnet:

# telnet localhost
Trying ::1...
telnet: connect to address ::1: Network is unreachable
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: unix1
Password:
Last login: Fri Aug 12 11:22:39 from localhost
Oracle Corporation      SunOS 5.10      Generic Patch   January 2005
$ exit
Connection to localhost closed by foreign host.

SSH:

# ssh unix1@localhost
Password:
Last login: Fri Aug 12 11:19:40 2011
Oracle Corporation      SunOS 5.10      Generic Patch   January 2005
$ exit
Connection to localhost closed.

Changing Password:

The user can change their password with the kpasswd(1) command:

$ kpasswd
kpasswd: Changing password for unix1@EXAMPLE.COM.
Old password:
New password:
New password (again):
Kerberos password changed.

12. Create a host principal keytab in Windows.

To create a host keytab in Windows, first a computer account must exist (this was created in the previous blog). Then create a host principal mapped to that user.

NB. Keytabs need to use the fully qualified domain name.

NB. Keytabs must use encryption which is supported by both ends. Suggestion: Either use /crypto all, or a known cryptosystem which is supported (eg AES256-SHA1).

There is a Security Policy, which has a checkbox list of all the Supported types:

Security Settings -> Local Policies -> Security Options -> Network Security: Configure encryption types allowed for Kerberos
DES_CBC_CRC
DES_CBC_MD5
RC4_HMAC_MD5
AES128_HMAC_SHA1
AES256_HMAC_SHA1
Future Encryption Types

eg (line split for easy reading)

C:\>C:\>ktpass /princ host/sol10host1.example.com@EXAMPLE.COM \
/ptype KRB5_NT_PRINCIPAL /out C:\temp\sol10host1.keytab /pass mypass \
/crypto AES256-SHA1 /mapuser EXAMPLE\sol10host1
Targeting domain controller: adserver.example.com
Successfully mapped host/sol10host1.example.com to SOL10HOST1$.
WARNING: Account SOL10HOST1$ is not a user account (uacflags=0x1021).
WARNING: Resetting SOL10HOST1$'s password may cause authentication problems if SOL10HOST1$ is being used as a server.

Reset SOL10HOST1$'s password [y/n]?  y
Password succesfully set!
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to C:\temp\sol10host1.keytab:
Keytab version: 0x502
keysize 90 host/sol10host1.example.com@EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) v
no 12 etype 0x12 (AES256-SHA1) keylength 32 (0x8664b66dd9235158a7097c60e5d57e6b7
73d092696bf71bb3dfa8fc2dc149b79)

This file can now be copied to /etc/krb5/krb5.keytab, and verified as follows:

# klist -ke
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  12 host/sol10host1.example.com@EXAMPLE.COM (AES-256 CTS mode with 96-bit SHA-1 HMAC) 

# kinit -k

If kinit doesn’t complain, then principal keytab is working, however, this might not be the end of the story. If an encryption scheme is not allowed, the following message may occur:

PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found

or

kinit(v5): Key table entry not found while getting initial credentials

See This Blog for information on keytabs and encryption.

12 Responses to Authenticating UNIX/Linux to Windows 2008R2. Part 2 : Solaris 10

  1. Mc.Sim says:

    Hi, Chris!
    When you create a keytab file is specified principal name “host”:
    /princ host/sol10host1.example.com@ EXAMPLE.COM
    many resources on the Internet are advised to set the parameter /princ in accordance with the service name, such as NFS to specify:
    /princ nfs/sol10host1.example.com@ EXAMPLE.COM
    Can you comment on that point?
    Thank you!

  2. Mc.Sim says:

    And also advised to only create the computer account, FREE user account.
    I would like also to hear from you!
    Thank you.

  3. Our Solaris 10 clients are using Windows 2008 R2 Active Directory for authentication (Kerberos) and (attempting) authorization (LDAP), but the LDAP part is erroring out. Here’s the sequence of events:

    On Solaris 10 client:

    ldaplist passwd \*

    -Works correctly, and lists all users from Windows 2008 R2 Active Directory

    However, when I do the same command for groups, it errors out:

    ldaplist group \*

    -Errors out with:

    ldaplist: Object not found

    The AD groups for UNIX I’ve chosen the NIS domain on the UNIX Attributes tab, just like I did with AD UNIX users.

    Other commands that do work between Solaris 10 and Win 2008 R2 AD:

    kinit
    klist
    klist -k
    ldapsearch -h -D cn=proxy,cn=users,dc=mydomain,dc=com -w -b dc=mydomain,dc=com -s sub ‘(cn=tst*)’
    ldapsearch -h -s base -b “” “(objectclass=*)”

    The ldapsearch will actually list my groups (my groups are named tstgrp1, tstgrp2, tstgrp3, tstgrp4), but I think this works because it’s searching for the Common Name (CN) tst*, and not for a type of object (group).

    These commands do not work as expected:

    getent passwd

    -This only shows local UNIX users

    getent group

    -This only shows local UNIX users

    The /etc/nsswitch.conf is set up for:

    passwd: files ldap [TRYAGAIN=continue]
    group: files ldap [TRYAGAIN=continue]
    hosts: files dns

    Systems:
    Solaris 10 (sparc)
    Windows 2008 R2 with Identity Management for UNIX Role added.

    • I found a mistake in our /var/ldap/ldap_client_file, I had:

      group:posixAccount=group

      And it should have read:

      group:posixGroup=group

      Once I made the change, I could query groups.

  4. Leo K says:

    I cannot seem to login in using any of the methods specified under section 11.
    LDAPSEARCH works
    KINIT works
    All attempts to log in results in nothing, no error message, no “password incorrect”; although I do get a password incorrect is I purposefully use the wrong address. I relieved my pam.conf file to what was listed on this and another site I was using for reference, they match.
    Also checked krb5.conf files, compared them to both sites, and they match.

    Any clue as to what might be going on.

    Thanks

    • Leo K says:

      Reconfirmed, I was mistaken, I am getting a “login incorrect” error.
      Have not been able to identify why yet.

      • Leo K says:

        OK, figured it out after hours of banging my head on the wall. Turn out the three lines suggested for /etc/pam.conf under the tutorial PART: Kerberos Encryption Types was not necessary, or at a minimum, incorrect. After commenting them out on at in PAM.conf, leaving RC4_HMAC_MD5 selected on the AD, I was able to log into the server with a default encryption level of AES-256.

      • Chris Wells says:

        I did need to override the encryption type for my AD DC. Maybe each DC has different settings.

      • Leo K says:

        Sol10 Server no longer works. Worked great for 2 days, but now I back to the getting “login incorrect” error messages.
        No settings were changed, I was working on the RHEL5 tutorial, when I noticed that I was unable to login with the unix1 account. I tested the account on the Sol10 Server, and could no longer log in?
        Is there an issue with the Domain Controller I missing?

      • Leo K says:

        OK, back working again.
        When creating the /etc/krb5/krb5.keytab file, the encryption specified makes a big difference. AES256-SHA1 broke logon attempts, RC4_HAMC_MD5 works when authenticating SOl10u10 with a WIN08R2 DC.

  5. qiao says:

    Hi do the same configuration as Part1,Part2
    now the domain user can’t login the soalris system and get access denied error
    can you give some suggestions?
    thanks

  6. Pingback: Confluence: Engineering

Leave a reply to Mc.Sim Cancel reply