AD object naming formats and examples

<>

Several formats for providing object names are supported by Active Directory. These formats accommodate the different forms a name can take, depending on its application of origin. Active Directory administrative tools display name strings in a default format, which is the canonical name. The following formats are supported by Active Directory and are based on the LDAP distinguished name:

LDAP Distinguished Name.
LDAP v2 and LDAP v3 recognize the RFC 1779 and RFC 2247 naming conventions
cn=jsmith,ou=promotions,ou=marketing,dc=noam,dc=reskit,dc=com

LDAP Uniform Resource Locator (URL):
LDAP://server1.noam.reskit.com/cn=jsmith,ou=promotions,
ou=marketing,dc=noam,dc=reskit,dc=com

Active Directory Canonical Name:
noam.reskit.com/marketing/promotions/jsmith

What is a Simple Bind

A user establishes a connection to a directory server by performing a bind operation. Part of the information that is used in performing this operation is the user's identity and password. There are three basic bind mechanisms ? anonymous, simple, or secure.

The simplest bind mechanism is an anonymous bind. Access is granted based on the user having no identity within the directory. While it is normal to provide read access to certain entries and attributes for anonymous users, most application data will be protected against retrieval by unknown users.

A simple bind operation is performed when the user provides a DN for an entry within the directory and a password that goes with that entry. The entry must have a USERPASSWORD attribute, which is checked against the password provided. If the bind is successful, the user's identity will become that DN for the duration of the connection and access to entries will be based on that identity.

While the simple bind is adequate for most environments, it requires that you send the password in clear text over the network. Some directory servers implement secure authentication methods, such as Kerberos or certificate-based authentication like SSL. Any authentication method that is used must resolve to a directory entry in order to permit a comparison with the access control list (ACL). After authentication, the ACL specifies access controls that are based on the DN for the user.


See original document at http://support.sas.com/rnd/itech/doc/ldap/ldapovew.html

Do we need a GC or do we not when logging in?

Since the authenticating DC queries GC for the universal group membership, so the short answer would be YES. But a complete answer is
1) if it's a single domain environment, because each DC contains all information, a GC is not needed;
2) if there is not native domain, there is not universal group, therefore GC is not needed (for log in)
3) if you log on as local users, you don't even need DC; If you log on as Domain Admins, you don't need a GC to log in domain
4) if there is cached credential, you don't have to talk to a GC

Added 09/03/02
5) When user logs in using UPN, GC will be queried to determine the domain membership
6) if the group membership is cached on a local DC, client may not need to contact a GC