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