1. Active Directory and Oxford Single Sign-On
Bridget Lewis – ICTST
Adrian Parks – OUCS
21st June 2007

2. Aim
How to link Active Directory to the Oxford Kerberos Single sign-on (SSO) infrastructure

3. What is Kerberos? Authentication protocol
Not authorisation
Client and server mutually authenticate
Adrian

4. Authentication vs Authorisation
Fred A. Stair
Undergrad
Cornflake College
Guest List
Donald Duck
Fred Smith
Lucy Jones
The Doctor
Fred A. Stair
AD normally does both  
Authenticated
Authorized

5. Why Kerberos? Single sign-on Centralised authentication
Strong encryption
No passwords over the wire
Adrian

6. Kerberos in Oxford Herald WebLearn Apache/IIS webservers (via Webauth)
eDirectory
Active Directory
Open Directory
Adrian: A number of web-based OUCS services already make use of Kerberos via Webauth
We can add directory services to this list using direct authentication by the KDCs

7. So how does it work…?
Simple, really…
Adrian

8. Like this…
Adrian: comedy equation
Any questions? No?

9. Basic Kerberos Functionality
Trusted Third Party A
1: A, B B S S
Client A
Bridget: Person A wants to talk to service B
A sends A’s name and B’s name to a Trusted Third Party (KDC)
KDC generates two copies of a session key
The KDC locks one copy with A’s password, and another copy with B’s password and sends both to A
A unlocks A’s copy with A’s password and forwards B’s copy to B
B unlock’s B’s copy with B’s password
A and B now each have a copy of the same session key
NB There is a standard security notation: this is not it!
B and the KDC never communicate
Client does all the work
The KDC and A must both know A’s password (or key)
The KDC and B must both know B’s password (or key)
Client A and service B must understand Kerberos protocol
In reality, it’s more complicated
So we have mutual authentication, and single sign on. Client only authenticates at the first stage (decrypting session key)
Service B B A 9

10. Essential Terminology
Principal — user or service with credentials
Ticket — issued for access to a service
Key Distribution Centre (KDC) — issues tickets for principals in a realm
Realm — set of principals in a Kerberos database, e.g. OX.AC.UK, OUCS.OX.AC.UK
TGT (ticket-granting ticket) — confirms identity; used to obtain further tickets (Single Sign-on)
Bridget - next few slides

11. Kerberos and Active Directory
Kerberos 5 implemented in AD (with added…)
Every domain is a Kerberos Realm
Every domain controller is a KDC
Many services can use Kerberos
CIFS, LDAP, HTTP
Kerberos is preferred over NTLM
Trusts between Kerberos Realms
B - same, but embraced and extended

12. Integrating Active Directory with Oxford Kerberos Realm
Configure Active Directory Kerberos realm to trust Oxford Kerberos realm for authentication
OX.AC.UK
KDCs 1 2
Client A
Trust 3 4 B
OUCS.OX.AC.UK
KDCs
Active Directory

13. Integrating Active Directory with Oxford Kerberos Realm
Authorization: AD uses SID, not username to determine what a user can do
Usernames must exist in AD (Identity Management)
Oxford usernames must be mapped to Active Directory users B 13

14. So what does this mean in practice?
The “Good”...
Use Oxford account to authenticate to AD
No need to issue passwords to new students each year
Devolve password problems to OUCS
Adrian

15. Case Study St Hugh’s College Integrated with Oxford KDCs
~ 20 Public Access PCs
~ 600 Students, intake of ~120 per year
Passwords were issued manually each year
Integrated with Oxford KDCs
Account creation simplified via VB script
Students use “Herald” password
Administrative overhead reduced for ITSS
Manual password – all sealed in envelopes, estimate full week of work, followed by p/w changes, might take a while. More efficient

16. Case Study Language Centre Webauth plus Oxford SSO solution
User base is whole university!
Potentially users
Historically, all used one shared account
Webauth plus Oxford SSO solution
Users register for AD account via Webauth protected site
AD account generated on the fly
Log in to AD via the Oxford SSO solution
“Herald password” 16

17. But…there are some caveats
The “Bad”...
Access from PCs not in domain
Including via web, e.g. Outlook WebAccess
Some students don’t know their Oxford password (approx 13%)
Loss of external connectivity to central KDCs
Bridget
If PC not in domain, Kerberos is not used (NTLM instead)
- cached logon vs lack of connectivity
- students who forward their - 13% according to recent statistics provided by sysdev (send them to Webauth)
- Essentially it’s not your problem, but one for OUCS!

18. ...and some problems The “Ugly”... Fallback authentication is NTLM
KDCs don’t speak NTLM
Some apps only speak NTLM
Problems integrating other operating systems (OS X, other?)
Bridget

19. Summary Works very well in certain scenarios
E.g. shared filestore for students
Reduced administrative overhead
Not appropriate for all environments
E.g. many services built on Active Directory (Exchange, Sharepoint, Web access to files etc.)
Bridget 19

20. How do we set this up? Full details are on the ITSS wiki:
Adrian: next slides up to demo

21. How do we set this up?
Check time is in sync (throughout domain and to ntp source)
See appendix for details! A 21

22. How do we set this up?
2. Request a Kerberos principal from the OUCS Systems Development team
krbtgt/FULL.AD.DOMAIN.NAME
krbtgt/STHUGHS.OX.AC.UK
krbtgt/ZOO.OX.AC.UK
Make sure you make it clear it’s for a cross-realm trust with an Active Directory domain, as certain attributes need to be enabled (preauth for example).

23. How do we set this up?
3. Change the password of the new principal (use linux.ox.ac.uk):
DES. Why are we either bothering. RC4 to follow!

24. How do we set this up?
4. Check time is in sync B

25. How do we set this up?
5. On all domain controllers, member servers and workstations, install the Windows Support Tools and run:
ksetup /addkdc OX.AC.UK kdc0.ox.ac.uk
ksetup /addkdc OX.AC.UK kdc1.ox.ac.uk
ksetup /addkdc OX.AC.UK kdc2.ox.ac.uk
Or use a registry file/Group Policy (see wiki)

26. How do we set this up?

27. How do we set this up?
6. Create a one-way, outgoing, transitive trust between the Kerberos realm OX.AC.UK and the Active Directory forest
Use the password set in step 3.

28. How do we set this up?
Set it up as transitive (although this doesn’t work yet)

29. How do we set this up?
7. Check time is in sync

30. How do we set this up?
8. Add a name mapping for AD account to the Kerberos realm
Format is
Note uppercase OX.AC.UK

31. How do we set this up?
Turn on Advanced Features from the View menu to see this!
(AP - AD U&C screenshot deleted as this presentation is going to be publically accessible)

32. How do we set this up? 9. Reboot workstation and log in
Now you can log in with your Oxford username, to the OX.AC.UK realm.

33. Demo

34. Contact details bridget.lewis@ict.ox.ac.uk adrian.parks@oucs.ox.ac.uk35

35. Some links ITSS Wiki: https://wiki.oucs.ox.ac.uk/itss/KerberosADTrust
MIT:
Designing an Authentication System: A Dialogue in Four Scenes
Microsoft:
Kerberos: The Definitive Guide (Jason Garman/O'Reilly)
ITSS wiki – step by step guide to what we’ve discussed today
MIT link – gentle explanation to how Kerberos works

36. Appendix A — Utilities 2003 Resource Kit Utilities
Kerbtray (GUI)
Klist (command line)
Support Tools Utilities (from 2003 CD)
Ksetup (command line)
Ktpass (command line)

37. Kerbtray Kerbtray displays tickets
Picture shows TGTs for ITSSCONFADDEMO.OX.AC.UK and OX.AC.UK

38. Kerbtray
Picture shows tickets for services in Active Directory Realm

39. Klist
Klist — as Kerbtray but command line

40. Support Tools Ksetup Ktpass Set up realm information
E.g. set KDCs for a given realm
Ktpass
Manipulating principals

41. MIT Kerberos for Windows
Another way of viewing tickets
Maintains its own ticket cache
Can import tickets from Microsoft cache
Some applications can use these tickets

42. Network Identity Manager

43. Appendix B — Additional Notes
Time must be within 5 minutes of KDC time
Logon may fail intermittently if logon allowed before network fully initialized (XP/2003)
Group Policy setting
Computer Configuration/ Administrative Templates/System/Logon
Enable setting "Always wait for network on computer startup or user logon"
Terminal Services Patch

44. Short History of Time All DCs sync to PDC emulator (automatic)
Member servers and workstations sync to Domain Controllers (automatic)
PDC emulator must be sync’d to ntp source
Must update if you move PDC emulator role
w32tm /config /manualpeerlist: "ntpserver1 ntpserver2 ntpserver3" /syncfromflags:manual /reliable:yes /update 45

45. Automated Account Creation
OUCS can provide nightly update of Oxford usernames and other information to each unit
Use scripts to feed into Active Directory 46

46. Full Kerberos Functionality
KDC — 2 parts
AS: Authentication Server
TGS: Ticket Granting Server AS A B
1: A, TGS C S S
TGS C
2: A, B
Client A
This slide is a masterpiece, if we do say so ourselves S S
KDC
Service B B A 47

47. Other notes of interest
Workstation authenticates too: problems for x-realm auth.
DC devolution — KDC patches available
Macs
eDir
preauth, timestamps, lifespan of tickets etc 48 48

48. Appendix C
Use Wireshark to observe the Kerberos exchange

49. Initial boot up – first, workstation NSMSVMXP$ authenticates directly to domain controller NSMSW2K1, Kerberos realm OUCS-TEST.OX.AC.UK (i.e. the Windows domain)

50. User sends initial request for a TGT to 163.1.2.74 (kdc0.ox.ac.uk)

51. KDC requires preauth, so user sends back preauth data (encrypted timestamp)

52. User now requests a cross-realm TGT for OUCS-TEST.OX.AC.UK

53. And now a request for an LDAP ticket, followed by some lookup for group policy etc in the AD