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 07:27AM, Sellers <email@hidden> wrote:

>Michael - thank you for your information. I use a third party LDAP
>server
>and not OpenDirectory - so knowing that may change my approach to auth
>here at OU.
>

It might be feasible to get things working using MCX- either from your server if you've mofified the schema, or client-side using static mapping or static mapping with variables in the LDAPv3 Plug-in. The easiest thing is to have a Mac OS X Server in the mix. Your users do not necessarily have to be in the server- you can use it solely for client management (by adding machines to a computer list) and configuring clients to access both nodes.

>Sellers
>
>On Apr 8, 2004, at 10:15 AM, Michael Bartosh wrote:
>
>>
>> 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.
>>>
>>>
>>>
>>>
>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.