Filter
Top Products
Disabled User Authentication
The Disabled User authentication is used to indicatethat an account has been disabled. The complete previous
authentication attribute value is retained in the authority data field and is enclosed by left and right angle
brackets. If the authority data field is absent, Basic authentication is assumed.
Here are some examples of properly formed authentication authority attribute values for Disabled User
authentication:
;DisabledUser;;ShadowHash;
;DisabledUser;<;ShadowHash;>
The left ( < ) and right ( > ) angle brackets around the old authentication authority value are optional. Any
tool that re-enables the user should check to see if the brackets are used and strip them when restoring the
original authentication authority value.
Multiple Authentication Attribute Values
An authentication attribute can have multiple values. When changing a password, all authentication authority
values are tried until the password is successfully changed or an error occurs. When verifying a password,
the order of authentication authority values determines which value is used first. The first authentication
authority that returns something other than eDSAuthMethodNotSupported is used. For example, Local
Windows Hash returns eDSAuthMethodNotSupported for all methods other than the change and set
methods, cleartext authentication, and the SMB LM and SMB NT authentication methods.
Authentication Versus Authorization
It is important to distinguish the difference between authentication and authorization:
■ authentication — a process that uses a piece of information provided by the user (typically a password)
to verify the identity of that user
■ authorization — the determination of whether a user has permission to access a particular set of
information
Open Directory allows an Open Directory client to use any method to authenticate a user. Open Directory
does not provide any facility for determining whether a user is authorized to access any particular set of
information. Moreover, Open Directory does not provide an authorization model. Instead, Open Directory
clients are responsible for granting or denying a user access to a particular set of information based on the
user’s authenticated identity.
When developing an authorization model, Open Directory clients must consider the following:
■ the authorization information to store
■ where and how to store authorization information
■ which applications can see, create, or modify authorization information
■ who is authorized to see and change authorization information
Often authorization is based on membership in a particular group.Many directory services store authorization
information in the directory service itself. These directory services use the identity that is currently being
used to access the directory service to determine whether to grant access to this information.
20
Open Directory Overview
2007-01-08 | © 2007 Apple Inc. All Rights Reserved.
CHAPTER 1
Concepts