Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: caching in Apple authentication mechanisms?

I could be 100% incorrect, but from observing the terminal in
Jaguar when bound to an LDAP server for authentication/user info,
there's no caching of uid, gid etc. If the connection to LDAP goes,
the machines can't determine the users uid, or gid.

Paul

On Wed, 7 Apr 2004, Albert Lunde wrote:

> On Wed, Apr 07, 2004 at 03:02:35PM -0500, Michael Bartosh wrote:
> > At 9:02 AM -0500 4/6/04, Albert Lunde wrote:
> > >We are trying to find out to what extent various authentication
> > >mechanisms available though Apple OpenDirectory cache user status.
> > >
> > >The context of this question is that we are trying to decide how to
> > >autheticate departmental MacOSX labs and computer clusters against our
> > >central authentication services.
> > >
> > >From a policy viewpoint, we'd like password changes or account
> > >activation/deactivation to take effect in a timely way.
> > >
> > >Implementation efficency probably dictates some caching, we'd like to
> > >know more about how much caching is done under what circumstances.
> > >
> > >The main altervatives we are considering are:
> > >
> > >(1) use of LDAP bind with SSL using the LDAPv3 plugin against our
> > >central LDAP server
> > >
> > >(2) use of the Active Directory plugin against a school-level Active
> > >Directory forest
> > >
> > >(3) MIT Kerberos against our central Kerberos server (or maybe Active
> > >Directory)
> > >
> > >(In all these cases, there will most likely be a different local LDAP
> > >server providing cluster-specific information for things like groups
> > >and Apple's management extensions.)
> > >
> >
> > I'm not really sure what your question is, but cached users' network
> > credentials are used whenever the node in question is available. In
> > terms of the AD plug-in, this means that password policies are
> > enforced whenever the DC can be contacted.
>
> To restate the question, in operational terms:
>
> For each of the authorization methods above...
>
> If we change a user's password or disable/enable their account on
> the central servers, how long will it be before a user is affected
> by the change on one of these lab machines. How much can the time
> vary and why?
>
> (We aren't too much interested in the case of off-network usage,
> here, though that is probably, as you say, something that AD
> treats explicitly, that the others ignore.
>
> The motivation is more to know how fast we can enforce policy-
> based changes in access.
>
> I assume some sort low-profile caching may be done for efficiency,
> based on the example of kerberos tickets and various kerberos/ldap
> apache modules I've seen. I have a vague sense I've seen something
> pro or con in the Open Directory literature I've read, but no citation.)
> _______________________________________________
> maclabmanager mailing list | email@hidden
> Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/maclabmanager
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
maclabmanager mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/maclabmanager
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: caching in Apple authentication mechanisms? (From: Albert Lunde <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.