FROM MIT KERBEROS TO MICROSOFT ACTIVE DIRECTORY The Pennsylvania State University’s move from a lower case MIT Kerberos realm to a Standard Microsoft Active Directory Deployment

OVERVIEW  Current state  MIT Kerberos “lower case realm name” passwords  Open LDAP  Central Domains:  ACCESS domain “Windows 2008 R2” external one-way trust  WIN domain “Windows 2008 R2” external one-way trust – Labs Only  60+ Other Windows domains  Current design does not support  Exchange  Majority of 3 rd party Apps and Hardware authentication and authorization  Local control of account live cycle

CAMPUS LOCATION MAP

BUSINESS REQUIREMENTS  Replace MIT Kerberos as authentication store  Central account and group provisioning  Foundation for other services (eg: Exchange, Skype, Office 365)  Improved PSU security posture  Restricted administrative accounts  Support of non MS clients and vended products  POSIXs Attributes  Custom Attributes

FUNDING FOR CHANGE  The current state could not support newer services  Security concerns of all Active Directory's - Security Need  No central ability to monitor all Account provisioning stores  Central Security office had no ability to monitor all Account stores  Bleed over from silos did not buy us security  Need ability to be more agile  Premier Microsoft Contract

CHALLENGES  Effort and resources  Up front costs  Team – 9 months to fully staff  Initial design started in March  Obstacles  No migration funding currently for units  No funding for auditing and logging  Other enhancements  Medical School <- Potential future challenge  Currently separate  Could potentially integrate at undetermined future date

TECHNICAL DESIGN  Support 180,000 accounts and 2 million groups “CPR, OpenLdap, Grouper”  Single Forest, Single Domain Design  2012 R2 Core  2012 R2 Forest Functional Level  External DNS  6 Prod Domain Controllers - 64 Gig of RAM, 4 CPUs  4 hosted in VMWare central service  2 on dedicated hardware  DNS  Bluecat Address Manager, formerly known as Proteus  Bluecat DNS/DHCP Server, formerly known as Adonis

NAMESPACE AND OU DESIGN  Lessons learned from other domains  Structure informed by location & Org Chart  Minimal depth  Facilitate delegated administration  Reduced logon time  Standard naming conventions  Newcomer friendly  Command-line friendly

OU DESIGN

SECURITY DESIGN  Administrative Accounts  Enterprise Admin, Domain Admin, Workstation Admin, Server Admin, OU Admin  Can only create OU Containers and Computer Objects  Self Service Portal  Create GPOs  Create Service Accounts  Create Keytabs  Central Authoritative source for accounts and groups  Central Identity Service for Account information  LDAP for additional attributes  Grouper and LDAP for group based administration

SECURITY PRACTICES  Protected privileged accounts  LAPS “Local Administrative Password Solution”  Secure Remote Desktop Service  GPOs to control runas service, logon as network, logon on locally, remote desktop logon  Protected Users group for Admin accounts  Red Forest?  Currently under investigation

RDS DESIGN PICTURE

WHAT DO YOU WANT TO KNOW?  Questions?

LINKS    Ignite Video on PtH  f_Pass-the-Hash.pdf f_Pass-the-Hash.pdf

BACKUPS     +Phases +Phases  +Phases+-+Deliverables

CURRENT AUTHENTICATION DESIGN