1. LocalSystem has not password and few privilege(as computer acccount), Service Account has the context of the domain account (Actually, LocalSystem does have a password just like your own account, but normally you don't have to worry about it)
2. Whenever you change password of a Service Account, you have to make change in the corresponding service properties via services console
3. LocalSystem on a DC has all rights against AD, so it's not recommended to use LocalSystem for starting a non-builtin service on DC
4. LocalSystem is subjected to remove when you remove the computer out of the domain, while Service Account remains in AD
Search This Blog
May 15, 2005
May 10, 2005
ObjectCategory vs. ObjectClass in a Search Filter
copy from "Windows 2000 Resource Kits"
Because of the existence of the class inheritance hierarchy in the schema, every object in Active Directory is in fact a member of many classes ? four or five on the average. For this reason, the objectClass index is prohibitively large (for example, 4n, where n is the number of objects in the system). In addition, objectClass has poor selectivity for many possible class values. For example, a search filter of (objectClass=securityPrincipal) returns every user and group object in the system.
On the other hand, objectCategory usually refers to the most specific class in the object's class hierarchy. Although objectClass can have multiple values, the attribute objectCategory has only one. Every Active Directory object has an objectCategory attribute whose value is a classSchema object.
Every classSchema object has an attribute called defaultObjectCategory, which is the object category of an instance of the class if none is specified by the user. For most classes, the defaultObjectCategory value is the class itself. In the search filter, you can specify objectCategory=X, where X is the ldapDisplayName of a class, and LDAP automatically expands the filter to objectCategory=. The objectCategory attribute has a syntax of distinguished name, and LDAP automatically converts the value for objectCategory to the distinguished name format. For example, if you use objectCategory=contact in the filter, the filter changes to objectCategory=cn=person,cn=schema,cn=configuration,dc= ("person" is the defaultObjectCategory for the class contact).
Because of the existence of the class inheritance hierarchy in the schema, every object in Active Directory is in fact a member of many classes ? four or five on the average. For this reason, the objectClass index is prohibitively large (for example, 4n, where n is the number of objects in the system). In addition, objectClass has poor selectivity for many possible class values. For example, a search filter of (objectClass=securityPrincipal) returns every user and group object in the system.
On the other hand, objectCategory usually refers to the most specific class in the object's class hierarchy. Although objectClass can have multiple values, the attribute objectCategory has only one. Every Active Directory object has an objectCategory attribute whose value is a classSchema object.
Every classSchema object has an attribute called defaultObjectCategory, which is the object category of an instance of the class if none is specified by the user. For most classes, the defaultObjectCategory value is the class itself. In the search filter, you can specify objectCategory=X, where X is the ldapDisplayName of a class, and LDAP automatically expands the filter to objectCategory=. The objectCategory attribute has a syntax of distinguished name, and LDAP automatically converts the value for objectCategory to the distinguished name format. For example, if you use objectCategory=contact in the filter, the filter changes to objectCategory=cn=person,cn=schema,cn=configuration,dc= ("person" is the defaultObjectCategory for the class contact).
May 8, 2005
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
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
Subscribe to:
Posts (Atom)