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?

On Thursday, April 08, 2004, at 05:31AM, Sellers <email@hidden> wrote:

>Ideally - caching will not occur with LDAP. If you change someone's
>password in LDAP, it will be
>virtually instantaneously changed to the 'clients'. The only plug-in
>that I have found thus far that supports offline authentication is the
>AD one.

Caching of Open Directory users- ie the LDAPv3 Plug-in- works fine. It might not ork though with a 3rd party LDAP server- at least not without some MCX settings and possibly an AuthenticationAuthority.

> Even still - I think that plugin is write to 'lookup first'
>and then fall back to previous information.

True.

>
>Now there is a concept of Name service caching (nscd on Solaris and
>Linux). This is a cache copy of name to uid matching, group to gid
>matching, etc. This is so when you type ls -la /home or open Finder
>with detailed views, it does not have to query the LDAP server for each
>and every file every time. It can do that once, store that information
>in cache, and then never have to do it again for that directory/file
>set for the cache-life period of time. This should not impact
>passwords, but may impact group membership. I don't off hand know
>what Apple uses for Name caching - if it's NetInfo or something part of
>the new LDAP stuff they are working on.
>

Both lookupd, which services libc lookups- and DirectoryService- which lookupd often passes that lookup off too- cach to some extent.

>
>
>On Apr 7, 2004, at 7:03 PM, 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.
>>
>>
>Chris G. Sellers Systems Programmer II
>Oakland University - University Technology Services - 220 DHE
>AIM : sellersOU WWW: www.oakland.edu/uts
>_______________________________________________
>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.



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.