lion auth (1 of 2)
TRANSCRIPT
Integrating Lion Into PSU Auth: A Case Study
Roy Long - [email protected] Gallagher - [email protected]
Monday, May 7, 12
First things first
Monday, May 7, 12
May the 4th be with you
Monday, May 7, 12
Session Info
• Lion Client / Server setup
• Making 3rd party Kerberos work
• 10.6 Server
• 10.7 Server
• Break
• Managing Lion Clients
• Profile Manager
• ASUS
• MCX
Monday, May 7, 12
Lion Integration
• Goals
• Zero Lion client changes
• Out of the box setup
• PSU Kerb w/ Local LDAP accounts
• 10.6.8 or 10.7 server
• working realm name to be department DNS name ie: astro.psu.edu not machinename.astro.psu.edu
• Minimal changes to OS X server (ie: not destroying the local KDC)
• Network home directories via NFS or AFP
Monday, May 7, 12
What we’ve learned...
• Existing 10.6.x installation instructions and setup does not work for bound Lion clients
• Similar steps using Lion Server also fail
Monday, May 7, 12
Making it work
• Setup the OD Master
• Install the keytabs for PSU AUTH
• tweak /Library/Preferences/edu.mit.Kerberos
• Bind the clients and go!
Monday, May 7, 12
Not so fast...
• 10.6 likes this, but clients login without a kerberos ticket.
• 10.7 fails. Miserably.
• opendirectory log is your friend
•$ odutil set log debug
Monday, May 7, 12
Heimdal Kerberos
• Syntax differences from MIT Kerberos
• Prefers UDP over TCP
• Appears quirky over edu.mit.Kerberos and /etc/krb5.conf
• Either file is valid but use only one
Monday, May 7, 12
The Setup
• 10.6.x server works great, but is extremely picky about the order of the setup.
Monday, May 7, 12
The Setup
• Virgin install of 10.6 Server
• Updates are great, but in our testing did not effect the outcome
• Do not enable ANY services...yet...
Monday, May 7, 12
The Setup
1. Install the keytabs firstktutil: rkt afpserver.tito.astro.psu.edu.keytab
ktutil: rkt cifs.tito.astro.psu.edu.keytab
ktutil: rkt host.tito.astro.psu.edu.keytab
ktutil: rkt ldap.tito.astro.psu.edu.keytab
ktutil: rkt nfs.tito.astro.psu.edu.keytab
ktutil: wkt /etc/krb5.keytab
ktutil: quit
2. Reboot
Monday, May 7, 12
The Setup
3. Enable OpenDirectory Service
Set the diradmin pass
Set the realm name: dept.psu.edu
Set search base: dc=dept,dc=psu,dc=edu
Monday, May 7, 12
The Setup
4. Time for edu.mit.Kerberos on the Servercp /Library/Preferences/edu.mit.Kerberos /Library/Preferences/edu.mit.Kerberos.orig
Replace with this:
[libdefaults]! default_realm = dce.psu.edu! dns_fallback = yes[domain_realm]! yourrealm.psu.edu = dce.psu.edu! .yourrealm.psu.edu = dce.psu.edu! .pass.psu.edu = dce.psu.edu! cifs.pass.psu.edu = dce.psu.edu! udrive.win.psu.edu = dce.psu.edu! .win.psu.edu = dce.psu.edu[logging]! kdc = FILE:/var/log/krb5kdc/kdc.log! admin_server = FILE:/var/log/krb5kdc/kadmin.log
Monday, May 7, 12
The Setup
5. Reboot
At boot the Server will read from this file only once
Monday, May 7, 12
The Setup
6. Add a user (or all of them)
a) Set the AuthAuthority
b) Save the User
7. Bind Lion client
8. Login
9. You’re done (almost)
Monday, May 7, 12
The Setup
Monday, May 7, 12
The Setup
Monday, May 7, 12
The Setup
• At this point, Lion clients will login
Monday, May 7, 12
The Setup
• At this point, Lion clients will login
• Note that you have not touched krb5.conf or edu.mit.Kerberos
Monday, May 7, 12
The Setup
• At this point, Lion clients will login
• Note that you have not touched krb5.conf or edu.mit.Kerberos
• Don’t worry, this configuration will break
Monday, May 7, 12
WTF?
Monday, May 7, 12
WTF?
• On the server, edu.mit.Kerberos appears to be read during the initial configuration
Monday, May 7, 12
WTF?
• On the server, edu.mit.Kerberos appears to be read during the initial configuration
• Subsequent boots appear to pull from the auto-generated data
Monday, May 7, 12
WTF?
• On the server, edu.mit.Kerberos appears to be read during the initial configuration
• Subsequent boots appear to pull from the auto-generated data
• Doing nice things like Software Update or adding a second network interface seem to snap the machine back into shape, er, sort of.
Monday, May 7, 12
WTF?
• On the server, edu.mit.Kerberos appears to be read during the initial configuration
• Subsequent boots appear to pull from the auto-generated data
• Doing nice things like Software Update or adding a second network interface seem to snap the machine back into shape, er, sort of.
• How do we fix it?
Monday, May 7, 12
edu.mit.Kerberos# WARNING This file is automatically created, if you wish to make changes
# delete the next two lines
# autogenerated from : /LDAPv3/ldap.astro.psu.edu
# generation_id : 459075342
[libdefaults]
! default_realm = dce.psu.edu
! dns_fallback = yes
[domain_realm]
! cifs.psu.edu = dce.psu.edu
! astro.psu.edu = dce.psu.edu
! .pass.psu.edu = dce.psu.edu
! udrive.psu.edu = dce.psu.edu
! .win.psu.edu = dce.psu.edu
! .astro.psu.edu = dce.psu.edu
[logging]
! kdc = FILE:/var/log/krb5kdc/kdc.log
! admin_server = FILE:/var/log/krb5kdc/kadmin.log
Monday, May 7, 12
Autogenerated edu.mit.Kerberos
Monday, May 7, 12
Autogenerated edu.mit.Kerberos
Monday, May 7, 12
Autogenerated edu.mit.Kerberos<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict>! <key>edu.mit.kerberos</key>! <dict>! ! <key>domain_realm</key>! ! <dict>! ! ! <key>.astro.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>astro.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>.pass.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>cifs.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>udrive.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>.win.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! </dict>! ! <key>libdefaults</key>! ! <dict>! ! ! <key>default_realm</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>dns_fallback</key>! ! ! <string>yes</string></dict>! </dict>! <key>generationID</key>! <integer>459075342</integer></dict></plist>
Monday, May 7, 12
Autogenerated edu.mit.Kerberos
Monday, May 7, 12
Autogenerated edu.mit.Kerberos
Monday, May 7, 12
Autogenerated edu.mit.Kerberos
11.Delete the hand modified edu.mit.Kerberos file
12. Reboot
Monday, May 7, 12
Yay!
Monday, May 7, 12
Yay!• At this point, the server no longer cares
about the static edu.mit.Kerberos file
Monday, May 7, 12
Yay!• At this point, the server no longer cares
about the static edu.mit.Kerberos file
• Clients will pull this info on first login following a reboot
Monday, May 7, 12
Yay!• At this point, the server no longer cares
about the static edu.mit.Kerberos file
• Clients will pull this info on first login following a reboot
• 10.6 clients can force update with:
Monday, May 7, 12
Yay!• At this point, the server no longer cares
about the static edu.mit.Kerberos file
• Clients will pull this info on first login following a reboot
• 10.6 clients can force update with:
kerberosautoconfig -u
Monday, May 7, 12
Yay!• At this point, the server no longer cares
about the static edu.mit.Kerberos file
• Clients will pull this info on first login following a reboot
• 10.6 clients can force update with:
kerberosautoconfig -u
• Copying the binary to Lion supposedly works, but not tested
Monday, May 7, 12
Increment by one each time you update<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict>! <key>edu.mit.kerberos</key>! <dict>! ! <key>domain_realm</key>! ! <dict>! ! ! <key>.astro.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>astro.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>.pass.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>cifs.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>udrive.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>.win.psu.edu</key>! ! ! <string>dce.psu.edu</string>! ! </dict>! ! <key>libdefaults</key>! ! <dict>! ! ! <key>default_realm</key>! ! ! <string>dce.psu.edu</string>! ! ! <key>dns_fallback</key>! ! ! <string>yes</string></dict>! </dict>! <key>generationID</key>! <integer>459075342</integer></dict></plist>
Monday, May 7, 12
10.6 Clients
• 10.6 clients will have edu.mit.Kerberos file
• Verify version by autogenerated numbers
Monday, May 7, 12
10.7 Clients
• edu.mit.Kerberos will not exist
• Neither will krb5.conf
• Obviously Lion client is reading and referencing the data, but not storing it in a flat file (that we’ve found)
Monday, May 7, 12
Bounty!
Monday, May 7, 12
Bounty!
• Where is Lion client storing this config data?
Monday, May 7, 12
Bounty!
• Where is Lion client storing this config data?
• I will personally thank you via email if you find it!
Monday, May 7, 12
Lion Server
• Similar steps to setup
• Syntax differences for adding keytabs
Monday, May 7, 12
Lion Server
1. Install the keytabs
cp /etc/krb5.keytab /etc/krb5.keytab.orig
ktutil copy afpserver.polo.astro.psu.edu.keytab /etc/krb5.keytab
ktutil copy cifs.polo.astro.psu.edu.keytab /etc/krb5.keytab
ktutil copy host.polo.astro.psu.edu.keytab /etc/krb5.keytab
ktutil copy ldap.polo.astro.psu.edu.keytab /etc/krb5.keytab
ktutil copy nfs.polo.astro.psu.edu.keytab /etc/krb5.keytab
ktutil -k /etc/krb5.keytab list
2. Reboot
Monday, May 7, 12
Lion Server
3. Setup OpenDirectory
(Same steps at 10.6)
Monday, May 7, 12
Lion Server
4. Add edu.mit.Kerberos or /etc/krb5.conf[libdefaults]
default_realm = dce.psu.edu
forwardable = true
proxiable = true
[domain_realm]
astro.psu.edu = dce.psu.edu
.astro.psu.edu = dce.psu.edu
.pass.psu.edu = dce.psu.edu
cifs.pass.psu.edu = dce.psu.edu
udrive.win.psu.edu = dce.psu.edu
.win.psu.edu = dce.psu.edu
[logging]
kdc = FILE:/var/log/krb5kdc/kdc.log
admin_server = FILE:/var/log/krb5kdc/kadmin.log
Monday, May 7, 12
Lion Server
Text
/System/Library/CoreServices/Directory Utility
Monday, May 7, 12
Lion Server
• At this point, 10.6 clients will work
• 10.7 syntax in edu.mit.Kerberos doesn’t seem to break 10.6
• Lion clients fail miserably
Monday, May 7, 12
Testing notes
• If you bind and unbind, reboot between steps
• Mixed results if not rebooted
• Start Server setup from virgin
• Mixed results if demoting an OD and starting again
• CCC via Thunderbolt is way cool
Monday, May 7, 12
Lion Client
• Lion client + Lion server just not happy
• Still working out why. Stay tuned.
• Small shim to Lion client fixes login problem
Monday, May 7, 12
Lion Client
• Changes to /etc/pam.d/authorization# authorization: auth account
auth optional pam_krb5.so use_first_pass use_kcminit
auth optional pam_ntlm.so use_first_pass
auth required pam_opendirectory.so use_first_pass nullok
account required pam_opendirectory.so
# authorization: auth account
auth sufficient pam_krb5.so use_first_pass
auth optional pam_ntlm.so use_first_pass
auth required pam_opendirectory.so use_first_pass
account required pam_opendirectory.so
Monday, May 7, 12
Lion Client
• Changes to /etc/pam.d/screensaver# screensaver: auth accountauth optional pam_krb5.so use_first_pass use_kcminitauth required pam_opendirectory.so use_first_pass nullokaccount required pam_opendirectory.soaccount sufficient pam_self.soaccount required pam_group.so no_warn group=admin,wheel fail_safeaccount required pam_group.so no_warn deny group=admin,wheel ruser fail_safe
# screensaver: auth accountauth sufficient pam_krb5.so use_first_passauth required pam_opendirectory.so use_first_passaccount required pam_opendirectory.soaccount sufficient pam_self.soaccount required pam_group.so no_warn group=admin,wheel fail_safeaccount required pam_group.so no_warn deny group=admin,wheel ruser fail_safe
Monday, May 7, 12
Lion Client
• Changes to /etc/pam.d/sshd# sshd: auth account password sessionauth optional pam_krb5.so use_kcminitauth optional pam_ntlm.so try_first_passauth optional pam_mount.so try_first_passauth sufficient pam_serialnumber.so try_first_pass serverinstallauth required pam_opendirectory.so try_first_passaccount required pam_nologin.soaccount required pam_sacl.so sacl_service=sshaccount required pam_opendirectory.sopassword required pam_opendirectory.sosession required pam_launchd.sosession optional pam_mount.so
Monday, May 7, 12
Lion Client
• Changes to /etc/pam.d/sshd# sshd: auth account password session
auth sufficient pam_krb5.so use_kcm_init
auth optional pam_ntlm.so try_first_pass
auth optional pam_mount.so try_first_pass
auth sufficient pam_serialnumber.so try_first_pass serverinstall
auth required pam_opendirectory.so try_first_pass
account required pam_nologin.so
account required pam_sacl.so sacl_service=ssh
account required pam_opendirectory.so
password required pam_opendirectory.so
session required pam_launchd.so
session optional pam_mount.so
Monday, May 7, 12
What we’ve learned
Monday, May 7, 12
What we’ve learned
• Lion and SL clients behave as expected with 10.6 server
Monday, May 7, 12
What we’ve learned
• Lion and SL clients behave as expected with 10.6 server
• Lion Server fails only with Lion clients
Monday, May 7, 12
What we’ve learned
• Lion and SL clients behave as expected with 10.6 server
• Lion Server fails only with Lion clients
• Searching for Lion Server solution
Monday, May 7, 12
What we’ve learned
• Lion and SL clients behave as expected with 10.6 server
• Lion Server fails only with Lion clients
• Searching for Lion Server solution
• Goal is to not make any client changes
Monday, May 7, 12
Recap
1. Install the keytabs first
2. Reboot the Server
3. Enable OpenDirectory Service
4. Put your edu.mit.Kerberos on the Server
5. Reboot the Server
6. Add Users & Fix AuthAuthority
7. Bind the Client
8. Test Logins
9. Fix auto-generated edu.mit.Kerberos
10. Reboot the Server
Monday, May 7, 12
Questions?
Monday, May 7, 12
[email protected] @[email protected] @scottgallagherhttps://wikispaces.psu.edu/display/
Lionkerbauth/Home
Thank You!
Monday, May 7, 12