WWDC2003 Session 607

Transcript

Kind: captions Language: en anyways we're here to talk about Apple open directory in specific authentication based on your support last year of the overflow room at San Jose they decided to give me two sessions this year so you can be bored this afternoon and I look forward to seeing all of you tomorrow and tomorrow morning's open directory sessions as the announcers said I'm David Rourke I'm the engineering manager for open directory and today we're going to talk about authentication what I'd like to do is review the current Jaguar feature set because I know everyone here some of the people might be new we're going to cover new features for authentication they break down into three basic areas we have local authentication open directory password server and what we're doing in that space Apple sink and Apple single sign-on / Kerberos implementation will do a summary we'll do a wrap-up and hopefully we'll have some time for Q&A if I don't go too long so Jaguar authentication the product that most of you probably had installed on your power books before we gave you the developer CD Jaguar currently support scripps all of us are familiar with crypt it supports the open directory password server it currently supports Kerberos its support cell defined and it supports any other method of authentication if you implement an open directory plug-in in Jaguar we introduce the new notion of a user attribute called the authentication Authority which is a hint to Jaguar as to how to best authenticate this user you're going to see later in this presentation and throughout the Panther process that we're going to start leveraging the authentication is already much more into the future so what authentication Authority values do we have right now we have basic and this is an attribute stored any user record and if its values basic it basically says the users using crypt if this attribute is absent we also assume the users using crypt because any existing user record that was crypt based didn't have an authentication authority so really the basic authentication authorities there for intellectual completeness that doesn't serve any purpose other than to clearly indicate this user script based the new attributes that we introduced in Jaguar was the Apple password server attribute this consisted of a keyword Apple password server which is up on the screen it's followed by a ID a public key of the password server and the network the password server that you would contact to authenticate this is how an LDAP or net info we indicate that the users authentication request should be redirected to talk to the Apple password server so for Jaguar changes we had a lot of infrastructure work to do we had to get login window onto directory services we had to get the church framework on the directory services we had to pama Phi the entire core OS most of the FreeBSD code we adopted wasn't adopting an API abstraction and because of that we couldn't replace the Crypt password and if we did these apps would would would break and we had the directory service api's of course had already supported this so the major accomplishment for Jaguar last year was that we managed to get most of apple's offer to not care how passwords are handled in puma or ten one that was not the case if you remove the crypt password there was a lot of software that broke so the major accomplishment for Jaguar was we got all of apple's software cleaned up not to care the open directory password server was also introduced with Jaguar with Jaguar server it's a password server is based on the open standard of saffell and it provides comprehensive network authentication supports for a wide variety of network protocols how many people have heard of a pop how many people have heard of crammed md5 NT land manager sha-1 shall I keep going the password server supports all of these methods so that you can have a single password supported across multiple network authentication protocols for those of you who have implemented authentication systems this is no easy trick so the authentication methods that we support with password server our md5 digests cram md5 in team land manager a pop webdav digest to a random and Apple's own disi Hellman exchange which is used by AFP I've associated the most common protocols that use each of these off methods but any protocol could in theory use any protocol any off method but you know and typically these are what their associated with all of these methods are secured to some degree if you believe network challenge response protocols are secure so none of these disclose the clear text password on the wire but all of them are necessary to support various network server protocols so last year I had a slide which I heard after the feedback was quite popular just runs you a quick diagram through how a password server authentication works for logging on to a mythical network service and I'd like to drop in a network so we have the mac OS 10 client it will be talking to the jaguar server AFP ftp IMAP SMB it's going to look the user record up in a directory server and it's going to verify that with a password server so the first thing that happens is the mac OS 10 client contacts the jaguar server and says hey I want AFP service I'd like to do to a random number exchange in my name is George the Jaguar server takes George looks them up in the directory server and what it retrieves from the directory servers George's name George's UID and in the very most important attribute as it retrieves the otha thority the author thority indicates that George is password server-based and this is the network address that this user should go to so the Jaguar server contacts the password server and conducts a network based authentication choosing an appropriate authentication method the password server responds with success even if the passwords wrong no I'm just kidding and the Jaguar server says you can log on or says no so this is very similar to Kerberos authentication for those of you but its password server based and there's no credential management going on here but the password server is the repository of the users passwords there are several advantages to the password server it maintains a single password for all network protocol part of apples strategy if you haven't heard this is we take open source offer make it easy to deploy well a lot of network administrators don't want to set a separate password databases for all their different networking protocols they want to create a user one so they want to assign a password once and they want to know that that user can log on to every single network protocol they might turn on today or tomorrow so the password servers role is to maintain a single password for all possible networking protocols that we support that remains weak that means we need to allow support for secure legacy network authentication protocols if you don't have this requirement you don't have to have a password server if you do have this requirement you have to have a password server most people have this requirement it also supports long passwords up to 511 bytes I picked bytes and not characters because utf-8 isn't necessarily a single byte per character for arbitrary strings it may be you know as little as 200 characters to the user types but it is 512 bytes it enforces password policies for all accounts it's not subject to hacking by download of hashes how many people are familiar with offline dictionary attacks in the audience you can't do that with the password server not even this password server administrator can capture the the hash is out of the password server database there's no known attack that I know of on the pastor server that can get the hashes into a user's hand where they can work them offline it supports standard security techniques such as slowing down unsuccessful failures policy to shut down the account after three or four failed attempts all of those standard things and more importantly it also has its own RSA public-key private key pair so the password server can't be spoofed in the design if you could set up the password server and take over an IP address and just have a password server that said yes every single time the client would trust what the password server would say and allow that user logon well the client when it's contacting the path server actually challenges the password server to prove it notes the private key so you cannot spoof being a password server on the network and we're going to leverage this more for some of the new features in jaguar jaguar Kerberos support thanks to our MIT brethren Jaguar came a full Kerberos support MIT provided us with a very robust Mac os10 Kerberos client an apple provided configuration documentation a lot more than what's listed here but that's one example document that Apple provided us how to configure Kerberos from Jaguar Apple carburized many servers and clients in the Jaguar timeframes there's the list for Jaguar client we Kerberos AFP weaker barytes the necklace chain mail application we terber eyes login window and kerberos helmet in Jaguar server we Kerberos AFP we Kerberos imap smtp I think we Kerber eyes pop did we curb eyes pop Marshall I don't know okay and we terber eyes the ftp server that we shipped with Jaguar server so Jaguar we did a lot of things we expanded to set of choices for authentication we abstracted the entire operating system to not care how passwords are managed and Panthers going to introduce any even more change now that we have these building blocks so what I'd like to get into is what you're all here for which is to talk about what we're doing an authentication for Panther and first we're going to talk about what changes we've made to local authentication and what I mean by local authentication are the user records that are kept locally on your powerbook that are created by the setup assistant or by the local system pref think not user records created by the server tools the first thing that most of you should stand up and applaud as crypt is dead there is no readable trip password the default local authentication is now stored in a shadow file for all local user accounts and that's strange bulleting there i had that file without a bullet file for all local user accounts is not its own bullet point anyway crip still works but no administration tools on Panther will create a crypt user no administration tools will create a crypt user it is not broken it's continued to be supported if there are legacy crypt users they will work just as well as they've always worked but no GUI tools that we ship with Panther will create the users with tripped your application should not be relying on crypt passwords Panther will break applications that require a readable crypt password this is not a bug it is a necessary evolution of the OS for us to close the security hole if your application requires a readable crypt password to authenticate a user you must adopt a password verification abstraction there are three abstractions that you could adopt to get off of readable crip passwords you could use Pam which is a pluggable authentication module from Linux we supported on mac OS 10 if you adopt Pam your application will not care how passwords are authenticated you can call the security framework it does a number of services for you I attended an excellent overview by the security team of the authorization framework you can adopt the security framework to do your password verification or you could work with us and adopt the directory service api's to do all of your passwords verification if your applications not using one of these api's it will break and has already been broken when running on Panther in your saw in the CD that we've distributed to you with Panther the default local user created by the setup assistant does not have a crypt password if you can't authenticate in your application with that user record it's not a bug in the OS it's a design decision and a security hole that we finally patched just in case this isn't clear your application is not using one of these api's it will break when running on Panther by the way your applications already broken on jaguar with the password server based user but most people don't know that and most people haven't tested with network users so this is not something new we're just tightening the noose a little bit in order to keep you guys employed so what have we done for the authentication authority matrix well we had basic that's crypt we still support that if you create a user you set the office thority to basic you'll get a Crip password we don't recommend it it's not secure we have the apple pastor server no changes there we still support the password server but we've added a new attribute that we call shadow hash a user record with an authentication authority of shadow hash indicates that a user record has a password hash stored in flash flour / DB / shadow that file is root readable only not even admin readable it's readable only to read the hashes out of that database you have to have root privileges on the local machine and on Panther root is not enabled by default so this is a secure as any system we know about the stores the passwords locally on a hard drive Panther stores all of its passwords for local users in VAR DB shadow it's a secure file system directory we use a sha-1 hash to store the password we have support for more than eight characters so those of you who want a character support and want it to be significant to more than a character support we now support that the system is no longer subject to hash download attacks of students cannot walk up to your lab machines run in I dump and walk off at the password database crypt is still supported as i said but no administration tools and Panther will create a crypt based user and all of the Panther command line tools that we've been able to identify have been updated to use the directory service api's to change passwords so you can now use change pw change password all the tools we found now use the DS API so you can change your passwords through command line or through the GUI so that's local authentication so authentication and Panther continues because we haven't been idle on what to do with network authentication as well so there are new features for the password server we have new authentication methods in the Panther password server we now support secure multi-master replication so the password server you can distribute copies of the Patrick server around your network and we've upgraded the client so the client knows about the replicas and will fail over to use a replica when one of the rep talking to you goes away we now have global and per user policies used to only be able to set password policies / user record which meant if you wanted to start in a global change you had to visit each user record well that was silly so we fixed it to have global policies and we're integrating support for Apple's Kerberos server which is really mi T's Kerberos server and I'm going to come back to that later in the presentation it's better performance there's far less networking traffic and extremely embarrassing faux paws takes 14 packets to authenticate a user on the password server how many of you think that's just hideous okay we fixed it and now takes two packets by the way if anyone can figure out how to do the authentication and single packet I want to talk to you after the session better performance less networking traffic and we have many new command line tools to automate policy management there's now a pw policy tool which lets you set all the policies from the command line it's an user / a spin on the server give it a try it has a man page the new authentication methods is we've added support for VPN authentication VPN a typical authentication method requires ms chap to the password server now offers ms chap to support and we and if you attended the server detail overview many of you are familiar now we have a PDC we had to had several authentication methods to support hosting a PDC so we added a number of auth methods so that we could host windows primary domain controllers so pastor server authentication methods look like this we have md5 digests that's supported on both platforms we have crammed md5 we have in TN land manager we have a pop we have webdav digest we have MS chap 2 which is new and only supported on Panther and we are retiring to a random every AFP client it's supported in Jaguar we're removing it in Panther because everybody since eight point one uses diffie-hellman the dhx exchange so to a random wasn't being used that much when we profiled all of our user data and there's some issues with it so we're retiring to a random and tim server there are other enhancements to the password server so new password policies I went over this global and / user password policies we now allow the policy to be set in one place so you can change your passwords from a minimum a character's to minimum 12 characters by making one single change or you can override for certain users there's that user who's calling you a lot on the phone line you don't like them you can set the password policy for them to be like 18 characters as a minimum password although I think that might cause more phone calls quite sure whether that's a good thing we have many new password policy features we have history we have character set requirements and there's a new tool for password policy management pw policy it's easier to show the new features than inventory them so i'm just going to throw up the screenshot and let you all get a good look at it so we can disable an account on a certain date we can disable an account after a certain number of days we can disable an account after a certain number of days of inactivity and inactivity in this realm is defined as successful activity so failed attempts don't keep this keeps us alive they have to have logged on successfully at least once within that period of time and we have the of course after certain number of failed attempts passwords must be a certain number of characters that contain at least a letter contain at least one numeric differ from the account name differ from the last ex passwords used and be changed every X minutes days months or years per user policies are a subset now you can override the global policies on a per user basis so I could go into a particular user say I've hired a contractor to come onto my site I want to disable it when the contractor goes away I can set a disabled logon you can see all of this in workgroup manager those are some of the policies we're supporting now and Panther secure replication slepping passwords around the network in the clear is not a good idea so when we designed replication from day one we've leveraged the public key private key pair that the password server have notes we use the ssh-keygen we don't share the ssh key but we use the exact same keygen tool that ssh uses to generate our keys so we are basing our replication on encryption done by using the public key private key pair that is already present on every password server that's already been deployed on jaguar replication can occur on change or it can occur periodically like every 20 minutes every half hour all replicas can accept change password that means if you're cut off from the mothership for a period I'm your users can still reset their passwords and when the replication occurs we merge the data and we do all the right things and knowing you know who has the later record all of that sort of stuff that you would expect from a professional server organization all replication sessions are encrypted in to end with 128-bit key using rc5 encryption that we get from the security framework there is no clear text data tapped at any time during password server replication I'd like to repeat that we never have the clear text on the wire client replica discovery is quite exhaustive if you have a replicated system but your clients are still beating on the same IP address it doesn't do you any good so we came up with a multi-layered approach for the client to discover a replica the replica picking is transparent to anyone using the directory service api's or any the higher-level api's you don't have to know that a failover is occurring replica discovery is done in parallel if you have 20 servers deployed in nineteen of them are down and you have a two-minute network timeout I doubt your user wants to make weight 38 minutes to find that the 20th replica so we discover the replicas in parallel the first thing we have we have a local cache file on on the Haute on the local machine that knows the IP address list of all the replicas for the password servers if we find the password server there we'll start working with that IP list first obviously in the genesis case we don't yet have that replica cash so we move on to a configuration record in the directory server so there is a config record in the LDAP directory server that is for the password server and it lists all the IP addresses of the password server the client downloads that configuration record and populates the cache file with that list we also use rendezvous which I'm going to come back to because we have public key private Carrie we can actually use her on demand is still secure and as a last ditch attempt we assume you might be trying to log on to a server for which you've changed its IP address and so will loop back to the local machine to see if a password servers running locally and authenticate there and the last resort will actually use the network address listed in the authentication authority if replicas available I think we'll find it I want to go back to the rendezvous case real quick the password server registers rendezvous using its public key we know the password server's public key so we can actually ask her on Naboo is there any password server on the network with with this public key now we don't trust that that password servers actually who says we still engage in the challenge to have that client proved to us that knows the private key but we were able to leverage rendezvous to use the service discovery protocol so that you can change the IP address of your password server and your clients will find them using rendezvous we thought that's pretty slick thought I might point it out to you where you have some security fallback it's kind of nice to combine rendezvous which is local network broadcast authentication or discovery with a secure authentication challenge Mike could be used for ssh as well and haven't thought about it much so integrated Kerberos support how many of you haven't heard that Apple's moving in a big way toward Kerberos okay so we are integrating test Luke's okay Apple will ship in enhanced MIT KDC I'm not sure the MIT team would think it's enhanced but no we're going to enhance it the enhancements will allow the pass or server in the KDC to share and synchronize their passwords and policy information Apple's KDC will leverage password server replication so all the KDC data will be funneled through password server replication sessions and from a customer's point of view the pasture server in the KDC or a single system so they won't know that they deployed a KDC they hopefully won't care because and if they do care we can say we're using Kerberos and then that should shut them up so legacy authentication support is still provided by the password server so what we have is in our opinion is the best of both worlds we're moving toward Kerberos but we aren't holding your legacy non Kerberos client hostage they can still engage in legacy authentication so this brings us to apples single sign-on strategy which is the last section of my presentation single sign-on this is defined as by my management as a user typing a password in the log on window and not having to worry about it ever again so Apple's adopting Kerberos as our network single sign-on approach Apple facing all of our Kerberos work on the MIT kerberos implementation Panther can be configured to work with existing Kerberos deployments Apple is not changing Kerberos we're tweaking the KDC but we're not changing Kerberos all we're really doing and I didn't realize this until we are almost done is we're providing configuration tools to make it easier to adopt Kerberos is excellent but Annapolis opinion has suffered some barriers to adoption and I'd like to go over some of those barriers so that hopefully you guys will share with me what you think we're actually adding that we're we're adding value so the first barrier to adoption is you needed a KDC you're required to deploy a KDC and up until now that's been quite an effort and up until Panther there was no KDC that ran on mac OS 10 I think heimdal ran but there was no am I TKD see that ran on panther or jaguar directory services integration this was actually fun Marshalls going to laugh at this but when we met four years ago at WWDC and San Jose what we'd realize is there were lots of Kerberos deployments in the world but none of them had standardized how do you integrate with the directory every site had done something slightly different so that's a barrier to adoption how do you integrate with the directory system lack of integrated user account management I mean there's lots of scripts and stuff but there's no GUI tool where I can say create a user and it also creates a kick with the Kerberos principle and does all the things you need to do you had to register all your hosting services so if I wanted to turn on an HP server I had to remember to create a host principal in my Kerberos server I just couldn't turn the piece over on or mail or some touch command line level configuration of the Kerberos clients I mean I can handle that but I don't think most of our customers can and there was no support for legacy network authentication if you deployed Kerberos there was no way for me to do an Indian land manager authentication for the windows 95 client that's never going to be curb erised so how do I get onto my SMB servers if it's been curb erised so we saw these as barriers to Kerberos adoption and the first thing we did was set out to dry each one of them so for Panther server requiring a KDC well we got that covered Panthers shipping with a full KDC set up by default if you complete the setup assistant on a panther server and have turned on a directory server you have deployed a KDC end of discussion no arguments no ifs no ands no buts directory server integration all the directory server tools and Panther know about the KDC and use the KDC lack of integrated user account management workgroup manager when you create new user will create a Kerberos principle for that user as well as a password server entry registration of all hosts and service principles if you complete the Panther setup assistant how many of you saw the cool auto setup assistant demo if you turn on all the services that you can turn on from Panther if you complete the setup assistant and there's a Kerberos server on the network we will have already pre-registered all the host principles for you for those services even if you haven't turned them on command line level configuration Panther desktop will optionally auto configure itself out of Kerberos there will be no command line configuration in Panther of Kerberos there can be if you prefer that but there will be no bottom there will be an option to have auto configuration no support for legacy network authentication we got that covered with the password server its whole reason for being as legacy network authentication we've integrated it with the KDC so you can have the best of both worlds you can support 50 / you can support ninety-five percent of your network as carburized and one or two machines that need to come in through a legacy protocol still can and still have the same password so Kerberos will be fully supported in Panther the Apple single sign-on changes don't modify Kerberos all we've done is provide some automated tools to assist the user with configuration Panther server will be Auto configured to use kerberos if Panther directory services are deployed but what about integrating with non-apple Kerberos systems well how many people deployed Kerberos at their site you guys already know how to do this so the way you'll do it for panthers the same way you've always done it for panther you've already you're already comfortable with the KDC you know how to create host principles there will be no difference in deploying Panther into an existing Kerberos deployment if you deploy our KDC you get the auto set features if you don't put a player out of our KDC you set it up the way you've always set up services to use the KDC the administrator is therefore responsible for the Kerberos configuration so I get this question a lot how does pants are actually auto configure Kerberos well we're using the authentication authority we now have defined an authentication authority in the user records with keyword of guess what Kerberos if we see an authentication authority with kerberos logon window will rummage around in the directory looking for kerberos config information and auto configure the Kerberos client if your directory contains that information your pants our client a lot of configure to use kerberos if your directory does not contain that information it will do nothing most directories don't contain this auto config information because we haven't told you what it is yet so your rest assured the Panther will not be automatically configuring Kerberos out of your directory system because we haven't even figured out ourselves yet with the final format of the data is but we will sites can add the auto configuration data to legacy deployments that they want we'll set it up for you automatically so we're leveraging the existence of the authentication authority in the user record and that will trigger Panther to look for config information to configure the client to use kerberos so customers can choose customers can choose to deploy Apple services and kerberos will be easier than ever many of the barriers to Kerberos adoption have been addressed in panther or customers can configure panther to work with existing Kerberos deployments no different than how they do other platforms so it's really up to use and network administrators to which system you deploy but either way Panther will support Kerberos authentication long term Apple is investing heavily in Kerberos where Apple can be an 800-pound gorilla we can actually make a lot we can actually make a lot of changes let me repeat the first statement we are investing heavily in Kerberos you should probably be doing the same we are aggressively migrating all of our networking products to be Kerberos based if it's appropriate we're going to ship at KDC we already ship a client in session 108 is a must-attend for any network services developer so you can learn how to use the Kerberos API all kerberos all the time is an apple future and yours planned today for the changes you know are coming I'd like to wrap it up at this point so Jaguar introduce new authentication support Panther has changes in three important areas we change local authentication and not bcrypt based we've enhanced the open directory passer server to be fully replicated there's new auth methods new policies new tools and apples aggressively working on making it trivial for server administrators to deploy Kerberos on their network an interesting history through the years is we started out with mac OS 10 oh and it's supported crypt 10-1 we added crypt ldap buying in the dfa p is for Mackel is 10 too we support crypt ldap Kerberos vs API password server Pam and security framework and for Panther we've dropped crypt we still have all the leg all the other support but we've added replication and moving out into the future Kerberos was more and more of the story and we're going to be working with MIT to define how that evolves and what and what we do there's some roadmap the security and architectural overview you should really go back in time and listen to that yesterday 108 is on thursday at 9am best Kerberos for mac OS 10 the immaculate end server of reviews also an excellent thing for time travel that was a 2pm Mackeson server and deaths preceded this so three of the sessions have already happened directory services is tomorrow I will be emphasizing the authentication far less and tomorrow's talk will be talking more about the enhancements to ldap and other things managed desktop technologies is heavily based on directory services i recommend if you're interested in directory services and authentication that's an excellent session and network security best practices is on friday at ten-thirty if you have any questions you can contact me or skip Levin's and for more information here's a list of documentation and open source references we have the directory service API documentation directory services is open source as part of Darwin we have the open directory SDK we have Mackel can't server documentation I particularly recommend the one in the technical briefs called open directory that's an excellent tutorial on the overview of what a directory system is we have mac lyst an ldap schema which is stored in the openldap configuration files and we have the mac-10 security api's there's also some third party sites openldap as an excellent ldap server saffell is done by carnegie mellon we base our password server on the sasal protocol pam is pam and it's a Linux password abstraction and there's Kerberos of course is web mit.edu / Kerberos Oh somebody added this slide I haven't seen it so who to contact about Kerberos would be on dreis wind occur is that correct Bob Fraser Katherine wink and enterprise level web object support and consulting I'm not quite sure that's appropriate for this session but maybe it is we have some more reference libraries that appear somebody cut and paste some slides into my presentation