Strongline's AD/Windows Notes

Attempt to remove glue record on delegated zone crashes DNS console

2012-01-22T22:37:00.001-05:00

- Windows 2008 R2
- 2 domains, parent-child
- 2 DNS zones respectively. Child zone delegated from parent zone
- Connect to parent DNS server, wrong IP listed for a name server in delegated zone properties window
- When try to remove or edit it, after confirmation, the MMC freezes

There are a few other people had same issue, seems to be a bug as far as I see it.

Resolution:
- ADSIedit, connect to parent DNS server
- Drill down to the delegated zone node
- In right hand pane, find the name server in question, remove the wrong IP from "dnsRecord(?)" attribute (you have to change the view to be "decimal" to see which entry is the wrong IP.

Largest Delta? What is it?

2011-12-19T11:16:00.001-05:00

Repadmin /repsummary result is simple, but yet somewhat confusing. A few notes:

If you don't specify /bysrc or /bydest, it will list status for both directions. You want to pay attention to Destination DSA as AD replication is pull-based.
Most critical column is "fails". If there is no fails, obviously you don't have much to worry about
Most confusing column is "largest delta". It's common misunderstanding (on the Net at least) that value in this column should be less then 1hr. However, depending on how large your AD environment is, and how frequent changes happen in a particular Naming Context, value in this column could be very large (days)
Microsoft's official interpretation for "largest delta": longest replication gap amongst all replication links for a particular DC", which is not really helpful. I personally had hard time to understand this interpretation itself.
This value is for the particular DC, among all its replication partners, the longest time that it hasn't replicated anything against whatever NC. This value has to be read together with /showrepl command against that DC.

Read on for example:

First, result for
repadmin /replsummary *

Replication Summary Start Time: 2011-12-19 10:52:16
.......

Destination DSA largest delta fails/total %% error

DC1 01d.08h:57m:06s 0 / 22 0

Then result for

repadmin /showrepl DC1

DC=john,DC=lab    Site1\DC2 via RPC
        DSA object GUID: 5920fcb0-f184-46ef-a231-962ceb436d7e
        Last attempt @ 2011-12-19 09:25:55 was successful.
    Site1\DC3 via RPC
        DSA object GUID: 136edad6-673a-41ab-9f80-bcd4ff61d78a
        Last attempt @ 2011-12-19 10:55:27 was successful.

CN=Schema,CN=Configuration,DC=john,DC=lab    Site1\DC2 via RPC
        DSA object GUID: 5920fcb0-f184-46ef-a231-962ceb436d7e
        Last attempt @ 2011-12-18 01:55:10 was successful.
    Site2\DC3 via RPC
        DSA object GUID: 136edad6-673a-41ab-9f80-bcd4ff61d78a
        Last attempt @ 2011-12-19 09:25:55 was successful.

[result truncated]

In above example, DC1 has DC2 and DC3 as its inbound partner for two NCs, domain default and schema. Among all 4 replication links, the one from DC2 for Schema was last done a day before, that is why the largest delta being reported is 1 day! But is it neccessay a concern? No. For one, Schema doesn't have much changes. And if there is no notification, target DC might just decide not to trigger the pull from source. For two, DC1 still gets latest update from other partners, such as DC3. I.e, it didn't miss anything because of the large delta reported. (BTW, I manully force a replication from DC3 to DC1 to generate above result).

You can acutally calculate the largest delta yourself:

largest delta = the time your run repadmin/replsummary - oldest "last attempt successful"

How to troubleshoot account lockout issue

2011-11-01T09:54:00.000-05:00

[Note] Event ID applicable to Windows 2003 DC only, but it shouldn't be too difficult to find related W2k8 event IDs.

Please read the differences between "Account Logon/logoff" event and "Logon/Logoff" event first.

- First, using lockoutstatus to find out initial authenticating DC (more than often PDC is not the initial authenticating DC. It has same event IDs mentioned below merely because other DCs check with PDC for latest password.) and time of logon attempt

- Then go to authenticating DC, check security log. Pin-point the log entry using time identified by lockoutstatus

- We are looking for: event ID 675 (4771 in w2k8?), the client IP is the offending machine that sent bad pwds

- Failure code in event ID 675(This is corresponding kerberos error code, full list here)

0x18: original wrong password
0x12: this will be logged after the fact that account has already been locked

- Logon type in event ID 675 ( full list here)

2 being interactive
3 network
5 service
10 Remote interactive

- Other events to look for:

client side

529(wrong pwd, on source member server, category Logon/logoff)
531(account is disabled, member server)
530(outside of allowed logon time window)
532(expired account)
533(lack of user rights)

DC side

644(account is locked, logged on DC),
675(wrong pwd, logged on DC, category Account Logon (changed to Credential Validation in 2k8), an event ID 4 kerberos should be logged as well in System Log),
676, obsoleted
681 obsoleted

- How to determine if it's a human error or application/service:

If there are large quantity of event 675, it's most likely from application

- Going extreme:

Enable netlogon log on PDC, authenticating DC, member server
First to look netlogon log on PDC, in which you can find the authenticating DC as well
How often the logon attempt happens
Error codes: full list here

Powershell: Predefined Variables

2011-10-26T09:29:00.000-05:00

Also called Automatic Variables.

Get-help about_automatic_variable

Time service commands

2011-10-18T13:01:00.000-05:00

Config a manual time source

w32tm /config /manualpeerlist:peers /syncfromflags:manual /update

Replace "peers" with a list of time servers, delimited by space, enclosed with double quotes.
Ignore KBs that maually set registry entries
Config a manual time source as the top time source in forest

w32tm /config /manualpeerlist:peers /syncfromflags:manual /reliable:yes /update

Detect time difference

w32tm /stripchart /computer:TimeServerName /samples:n /dataonly

Set server to use domain hierarchy

w32tm /config /syncfromflags:domhier /update

After change time settings, it's normally required to restart time service

If there is time difference, it takes time for the system to bring the difference down depending on how much correct can be made in one step. The change is gradual.

Token Size vs. Paged Pool - draft

2011-10-05T14:25:00.002-05:00

This is mostly a complete copy from microsoft.com

When users access a resource using Windows authentication and authorization (for example logging on to a workstation or accessing a file share), an “access token” is built to represent that user.
      The number of SIDs (representing group membership, etc) in that token largely determines how much kernel memory space (Paged Pool) is required to store each copy of the token.
      These allocations follow a “stair-step” pattern, as follows:
      At approximately 84 SIDs, allocation jumps from 4KB to 8KB.
      At approximately 177 SIDs, allocation jumps from 8KB to 12KB.
      At approximately 270 SIDs, allocation jumps from 12KB to 16KB.
      At approximately 363 SIDs, allocation jumps from 16KB to 20KB and so on.

      As many users connect concurrently to shared resource servers such as Exchange servers, domain controllers, file servers, etc, the risk of exhausting Paged Pool resources increases. In particular the risk increases as user/connection counts increase and as each copy of each user’s token increases in allocation size.
      For example, on a server with 70MB of Paged Pool available for safely storing new tokens, assuming 7 tokens per user (many applications use multiple concurrent authenticated sessions per user), the server can handle approximately:
      2560 users having 4KB tokens, or
      426 users having 24KB tokens

When users access a resource using Windows authentication, and Windows authorization is using Kerberos, the client machine passes a Kerberos ticket to the resource server in-line with the application layer traffic.
      In the case of HTTP, Kerberos tickets are typically included in the header portion of certain HTTP requests from the client to the server.
      As users become members of more and more security groups, their Kerberos tickets increase in size. Eventually the tickets may become large enough to exceed size limit restrictions on HTTP header structures.
      IIS 5 (Windows 2000 Server) has a default header size limit of 16KB (a.k.a. “MaxClientRequestBuffer”).
      The exact Kerberos ticket size that will lead to exceeding this threshold will vary considerably based on the following factors:
      • In HTTP user’s Kerberos tickets are encoded as Base64, which typically increases their size relative to default encoding for other ticket scenarios. Note that the growth ratio may vary from one ticket to the next. In lab testing an average growth ratio of roughly 8/5 was observed. In other words, a Kerberos ticket which is estimated by this tool to be approximately 10KB (under normal circumstances, before accounting for http specific encoding) would be likely to exceed the IIS header size limit of 16KB.
      • The user’s Kerberos ticket must share the HTTP header space with other header elements. In some cases these other elements may be very large and further reduce the space available for the encoded ticket.
      • Kerberos delegation roughly doubles ticket size. As this tool must take a conservative approach it must assume that delegation may be in use at least somewhere in the enterprise and therefore assumes delegation when estimating ticket sizes.
      Based on the above factors, the tool estimates a ticket size using delegation and considers an estimated ticket size of 10 KB to be likely to exceed the IIS 16KB limit. Considering the above variability, this threshold should be considered a useful signpost, while acknowledging that individual users and scenarios may encounter problems above or below this threshold.
      Also note that in addition to IIS, other software and devices (such as firewalls, intrusion detection systems, 3rd party web servers, etc) may impose limits on HTTP header sizes.
      These options can be used in any combination to achieve the desired results
      • Reduce group memberships
      • Clean up SID History
      • Modify IIS settings to increase the allowed HTTP header size.
      These are steps that must be taken carefully to avoid unexpected access control or other repercussions.
      Strong group creation, ownership, maintenance and lifecycle policies (enforced through identity management processes) are long term keys to managing group sprawl.

Programer's Font On Windows 7

2011-09-21T09:32:00.000-05:00

I've been looking for a font on Windows 7 that's good for scripting. The two main requirements are:

It has to be fixed width (monospace) (of course!);
It can easily let you tell the difference between a 0 (zero) and an O (as in Oops!)

There are a lot nice fonts but filtered by above two criteria and native to Windows 7, it comes down to Consolas.

2011 Microsoft Scripting Game - Advanced Leader Board

2011-07-18T09:18:00.000-05:00

I was recently in the Scripting Guy 2011 game advanced group and placed 32nd overall. Not too bad :-) considering I didn't have enough time to finish all scripts (I've done 8 out of 10), neither did I have time to polish my scripts which costed quite a few points :-(. Nevertheless it's a great experience. I learned a lot new PowerShell techniques along the way!

2011 Advanced Group Final Leader Board

Using System Namespace In Powershell

2011-04-20T10:21:00.000-05:00

There are many cool pre-defined constants, functions, methods, and etc. in System object. One would normally learn individual ones through sample scripts, but really should browse the MSDN page to explore what System namespace has to offer. Goto a class/structure/enumeration that you are interested, then pay special attention to those static members.

A few examples:

[System.DateTime]::Today versus [System.DateTime]::Now
[System.String]::Empty
[System.Console]:: almost everything are static, not surprisingly
[System.Math]::PI

There are also a bunch of other namespaces, please see .Net Framework Libraries

Local Admin Account vs. account lockout

2010-12-14T14:48:00.001-05:00

You can't really lock out an admin account - as long as you type in the correct password on *local console*, the system will unlock it automatically. This makes sense - legit users need a way to get into the system when all other credentials are failed - completely locking out all users surely won't make happy customers.

However this increases the risk of being cracked by brutalforce method. For companies who want to maximize the security and are willing to pay the cost of losing acceess due to lost passswords, there is a way to put admins under same lockout policy as ordinary users. MS has an old tool called passprop.exe that can enforce lockout policy, even against admins.

passporp /adminlockout

This is no longer needed in Windows 2008. There are pre-define security polices in Windows 2008 will do the same.

LDAP search can't find secondary email addresses

2010-12-14T14:39:00.000-05:00

You can search primary address using filter like (mail=JohnDoe@foo.com), but similar filter (proxyAddresses=johnDoe@foo.com) won't return anything. This is because attribute "proxyAddresses" holds not only smtp addresses, but also other types, e.g. RightFax, X.25, as well. To search secondary smtp addresses, you need to define a filter like this

(proxyAddresses=smtp:johnDoe@foo.com)

Java JDNI Authentication Against AD

2010-10-28T12:06:00.005-05:00

Keep in mind that some of the mechanisms require the user's password stored in reversible format and password be reset.

JNDI, Active Directory and Authentication (Part 1) (Kerberos)
http://forum.java.sun.com/thread.jspa?threadID=579829&tstart=300

JNDI, Active Directory & Authentication (part 2) (SSL)
http://forum.java.sun.com/thread.jspa?threadID=581425&tstart=50

JNDI, Active Directory & Authentication (part 3) (Digest-MD5)
http://forum.java.sun.com/thread.jspa?threadID=581868&tstart=150

JNDI, Active Directory & Authentication (part 4) (SASL EXTERNAL)
http://forum.java.sun.com/thread.jspa?threadID=641047&tstart=0

JNDI, Active Directory, Paging and Range Retrieval
http://forum.java.sun.com/thread.jspa?threadID=578347&tstart=0

JNDI, Active Directory, Referrals and Global Catalog
http://forum.java.sun.com/thread.jspa?threadID=603815&tstart=15

JNDI, Active Directory (Creating new users & demystifying userAccountControl)
http://forum.java.sun.com/thread.jspa?threadID=582103&tstart=15

JNDI, Active Directory & Changing Passwords
http://forum.java.sun.com/thread.jspa?threadID=592611&tstart=50

JNDI, Active Directory and Group Memberships
http://forum.java.sun.com/thread.jspa?threadID=581444&tstart=150

JNDI, Active Directory and objectGUID's
http://forum.java.sun.com/thread.jspa?threadID=585034&tstart=150

JNDI, Active Directory and SID's (Security Identifiers)
http://forum.java.sun.com/thread.jspa?threadID=585031&tstart=150

JNDI, Active Directory and Error codes
http://forum.java.sun.com/thread.jspa?threadID=578674&tstart=200

JNDI, Active Directory and Server Side Sorting
http://forum.java.sun.com/thread.jspa?threadID=628857&tstart=0

JNDI, Active Directory & Persistent Searches (part 1)
http://forum.java.sun.com/thread.jspa?threadID=578338&tstart=200

JNDI, Active Directory and Persistent Searches (part 2)
http://forum.java.sun.com/thread.jspa?threadID=578342&tstart=200

Sample code demonstrating a search for disabled accounts.
http://forum.java.sun.com/thread.jspa?threadID=588430&messageID=3045217

JNDI, Active Directory and User Account status (account expired, locked)
http://forum.java.sun.com/thread.jspa?threadID=716240&tstart=0

JNDI, Active Directory and Authentication (part 5, LDAP Fastbinds)
http://forum.java.sun.com/thread.jspa?threadID=726601&tstart=0

How LDAP Error Codes Map to JNDI Exceptions

2010-10-28T08:31:00.001-05:00

LDAP Status Code Meaning Exception or Action
0 Success Report success.
1 Operations error NamingException
2 Protocol error CommunicationException
3 Time limit exceeded. TimeLimitExceededException
4 Size limit exceeded. SizeLimitExceededException
5 Compared false. Used by DirContext.search(). Does not generate an exception.
6 Compared true. Used by DirContext.search(). Does not generate an exception.
7 Authentication method not supported. AuthenticationNotSupportedException
8 Strong authentication required. AuthenticationNotSupportedException
9 Partial results being returned. If the environment property "java.naming.referral" is set to "ignore" or the contents of the error do not contain a referral, throw a PartialResultException. Otherwise, use contents to build a referral.

10 Referral encountered. If the environment property "java.naming.referral" is set to "ignore", then ignore. If the property is set to "throw", throw ReferralException. If the property is set to "follow", then the LDAP provider processes the referral. If the "java.naming.ldap.referral.limit" property has been exceeded, throw LimitExceededException.
11 Administrative limit exceeded. LimitExceededException
12 Unavailable critical extension requested. OperationNotSupportedException
13 Confidentiality required. AuthenticationNotSupportedException
14 SASL bind in progress. Used internally by the LDAP provider during authentication.
16 No such attribute exists. NoSuchAttributeException
17 An undefined attribute type. InvalidAttributeIdentifierException
18 Inappropriate matching InvalidSearchFilterException
19 A constraint violation. InvalidAttributeValueException
20 An attribute or value already in use. AttributeInUseException
21 An invalid attribute syntax. InvalidAttributeValueException
32 No such object exists. NameNotFoundException
33 Alias problem NamingException
34 An invalid DN syntax. InvalidNameException
35 Is a leaf. Used by the LDAP provider; usually doesn't generate an exception.
36 Alias dereferencing problem NamingException
48 Inappropriate authentication AuthenticationNotSupportedException
49 Invalid credentials AuthenticationException
50 Insufficient access rights NoPermissionException
51 Busy ServiceUnavailableException
52 Unavailable ServiceUnavailableException
53 Unwilling to perform OperationNotSupportedException
54 Loop detected. NamingException
64 Naming violation InvalidNameException
65 Object class violation SchemaViolationException
66 Not allowed on non-leaf. ContextNotEmptyException
67 Not allowed on RDN. SchemaViolationException
68 Entry already exists. NameAlreadyBoundException
69 Object class modifications prohibited. SchemaViolationException
71 Affects multiple DSAs. NamingException
80 Other NamingException

What Certificate Authorities You (Are Forced to )Trust and Why

2010-09-27T10:56:00.002-05:00

In our real life, any identity issuing agency gets their power from government that people elected. You can't just claim you can/want to issue identity certificates because nobody is going to trust what you issue.

Then why the heck that there are so many "trusted" root CAs in our operating systems that we didn't endorse? In other words we are forced to trust some companies that we didn't elect. How did those CAs get their "trusted" status?

The answer is that it's Microsoft who decides what CAs it wants to add into its Windows trusted list. They have a program called "Microsoft Root Certificate Program". As long as you meet MS' requirements, you can apply and (hopefully) get the same status as big guys as VeriSign, Thawte, etc.

Not surprisingly, you can expect that other main stream OSes/browsers have same kind of programs.

Some may argue that why should Microsoft make the choice on their behalf. Well, if you decided to use Windows, you, intentionally or unintentionally, decide to trust whatever Microsoft put on the system anyway, don't you? We can only trust that Microsoft's verification program will do their job.

Want to know who is in the list being trusted? Please see KB931125

Access denied when open a network drive

2010-09-17T13:17:00.000-05:00

When openning a network drive, what is the difference between double clicking the driver letter versus typing the letter in address bar then enter? No really you would think.

I was troubleshooting a ticket where a user got "Access Denied" by double clicking in the meantime using address bar worked just fine. Needless to say, permissions are all correct on the netwokr share. It's just how you access it. The issue follows the user so I looked up and down in the user's properties in AD and group policies but failed to find anything.

It turned out it was caused by a little file, autorun.inf, under the root of that network drive. By double clicking the system tried to run it and it required something that this user didn't have permission to. Removing the file resolved the issue!

AD limitations and scalability

2010-04-28T11:49:00.004-05:00

This topic describes Active Directory scalability and other limitations, as well as recommendations that apply when you are designing or implementing an Active Directory infrastructure. These limitations include the following:

Maximum Number of Objects
Maximum Number of Security Identifiers
Maximum Number of entries in Discretionary and Security Access Control Lists
Group Memberships for Security Principals
FQDN Length Limitations
File Name and Path Length Limitations
Additional Name Length Limitations
Maximum Number of GPOs Applied
Trust Limitations
Maximum Number of Accounts per LDAP Transaction
Recommended Maximum Number of Users in a Group
Recommended Maximum Number of Domains in a Forest
Recommended Maximum Number of Domain Controllers in a Domain
Recommended Maximum Kerberos Settings
Maximum Number of Objects

Each domain controller in an Active Directory forest can create a little bit less than 2.15 billion objects during its lifetime.

Each Active Directory domain controller has a unique identifier that is specific to the individual domain controller. These identifiers, which are called Distinguished Name Tags (DNTs), are not replicated or otherwise visible to other domain controllers. The range of values for DNTs is from 0 through 2,147,483,393 (231 minus 255). As objects are created on a domain controller, a unique value is used. A DNT is not reused when an object is deleted. Therefore, domain controllers are limited to creating approximately 2 billion objects (including objects that are created through replication). This limit applies to the aggregate of all objects from all partitions (domain NC, configuration, schema, and any application directory partitions) that are hosted on the domain controller.

Because new domain controllers start with low initial DNT values (typically, anywhere from 100 up to 2,000), it may be possible to work around the domain controller lifetime creation limit—assuming, of course, that the domain is currently maintaining less than 2 billion objects. For example, if the lifetime creation limit is reached because approximately 2 billion objects are created, but 500 million objects are removed from the domain (for example, deleted and then permanently removed from the database through the garbage collection process), installing a new domain controller and allowing it to replicate the remaining objects from the existing domain controllers is a potential workaround. However, it is important that the new domain controller receives the objects through replication and that such domain controllers not be promoted with the Install from Media (IFM) option. Domain controllers that are installed with IFM inherit the DNT values from the domain controller that was used to create the IFM backup.

At the database level, the error that occurs when the DNT limit is reached is “Error: Add: Operations Error. <1> Server error: 000020EF: SvcErr: DSID-0208044C, problem 5012 (DIR_ERROR), data -1076.”

Maximum Number of Security Identifiers

There is a limit of approximately 1 billion security identifiers (SIDs) over the life of a domain. This limit is due to the size of the global relative identifier (RID) pool of 30 bits that makes each SID (that is assigned to user, group, and computer accounts) in a domain unique. The actual limit is 230 or 1,073,741,823 RIDs. Because RIDs are not reused—even if security principals are deleted—the maximum limit applies, even if there are less than 1 billion security principals in the domain.

Note

RIDs are assigned in blocks of 500 by default from the domain controller that holds the RID operations master role in each domain. If a domain controller is demoted, the unused RIDs that were allocated to the domain controller are not returned to the global RID pool and are therefore no longer available for use in the domain.

When all the available RIDs are assigned for a domain, the Directory Service log in the Application and Service Logs of Event Viewer also displays Event ID 16644 from an event log source of the Security Accounts Manager (SAM) that reads “The maximum domain account identifier value has been reached. No further account-identifier pools can be allocated to domain controllers in this domain.” If you run Dcdiag when all the available RIDs are assigned for a domain, you see the error message “The DS has corrupt data: rIDAvailablePool value is not valid.”

A partial work-around to this limitation is to create an additional domain to hold accounts and then migrate accounts to the new domain. However, you must create a trust relationship to migrate accounts in advance of reaching the limit. Creating a trust requires the creation of a security principal, which is also known as a trust user account. For more information about this limit, see articles 316201 (http://go.microsoft.com/fwlink/?LinkID=115211) and 305475 (http://go.microsoft.com/fwlink/?LinkId=115212) in the Microsoft Knowledge Base.

Note

The Active Directory database does not set limits on the number of objects in a container, such as organizational units (OUs). You might experience limits when you work with multiple thousands of objects. These limits are configured to help provide a certain level of application or service availability. For example, the Active Directory Users and Computers snap-in is configured by default to display a maximum of 2,000 objects per container. You can adjust this value by using the Filter Options settings on the View menu. There are also adjustable Lightweight Directory Access Protocol (LDAP) policies that are set by default to improve domain controller performance. These policies are described in article 315071 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=135481).

Maximum Number of entries in Discretionary and Security Access Control Lists

The limitation for the number of entries in a discretionary access control list (DACL) or a security access control list (SACL) of an Active Directory object using the ntSecurityDescriptor attribute comes from a limitation in the size of the access control list (ACL), which is 64K. Since access control entries (ACEs) vary in size, the actual number of entries (SIDs) is approximately 1,820. For additional details, see How Security Descriptors and Access Control Lists Work (http://go.microsoft.com/fwlink/?LinkId=214683).

Group Memberships for Security Principals

Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately 1,015 groups. This limitation is due to the size limit for the access token that is created for each security principal. The limitation is not affected by how the groups may or may not be nested. For more information, see article 328889 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115213). For a detailed discussion of access token limitations, see Addressing Problems Due to Access Token Limitation (http://go.microsoft.com/fwlink/?LinkId=146571).

For more information about how a domain controller creates the data structure that is used for authorization decisions, see:

[MS-PAC]: Privilege Attribute Certificate Data Structure (http://msdn.microsoft.com/en-us/library/cc237917(PROT.13).aspx)

3.3.5.3.2 Initial Population of the PAC (http://msdn.microsoft.com/en-us/library/cc233956(PROT.13).aspx)

3.3.5.4.3 Domain Local Group Membership (http://msdn.microsoft.com/en-us/library/cc233950(PROT.13).aspx)

FQDN Length Limitations

Fully qualified domain names (FQDNs) in Active Directory cannot exceed 64 characters in total length, including hyphens and periods (.). For example, the following host name has 65 characters; therefore, it is not valid in an Active Directory domain:

server10.branch-15.southaz.westernregion.northamerica.contoso.com

This is an important limitation to keep in mind when you name domains. This limitation is due to the MAX_PATH length of 260 characters that the Win32 application programming interfaces (APIs) define, in combination with the way in which Group Policy objects (GPOs) are stored in the SYSVOL share. For more information, see article 245809 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115219). For more information about naming limitations, see article 909264 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=106629).

File Name and Path Length Limitations

The physical files that Active Directory components use, such as SYSVOL, database (NTDS.DIT), and log file paths, are constrained by the MAX_PATH length of 260 characters, as defined by the Win32 APIs. When you are determining where to place your SYSVOL and database files during Active Directory installation, avoid nested folder structures that make the full file path to the SYSVOL folder, database, and log files longer than 260 characters. For more information, see article 245809 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115219).

Additional Name Length Limitations

There are additional limitations regarding name lengths in Active Directory. The following limits are described in article 909264 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=106629):

NetBIOS computer and domain names are limited to 15 characters.

Domain Name System (DNS) host names are limited to 24 characters.

OU names are limited to 64 characters.

Name Length Limits from the Schema

Default limits on attribute names for Active Directory objects that are imposed by the schema include the following. These items provide examples of schema-limited name attributes:

Display names are limited to 256 characters. For more information, see Display-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153705).

Common names are limited to 64 characters. For more information, see Common-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153706).

The SAM-Account-Name attribute (also known as the pre–Windows 2000 user logon name) is limited to 256 characters in the schema. However, for the purpose of backward compatibility the limit is 20 characters. For more information, see SAM-Account-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153707).

Name Length Limitations for LDAP Simple Bind Operations

During binds to the directory, simple LDAP bind operations limit the distinguished name (also known as DN) of the user to 255 total characters. If you attempt a simple LDAP bind with more than 255 characters, you might experience authentication errors, such as the following:

Copy Code

Error <49>: ldap_simple_bind_s() failed: Invalid Credentials

Server error: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 57, v1771

Error 0x80090308 The token supplied to the function is invalid

You can avoid this issue by ensuring that the applications, scripts, and utilities that attempt to bind to your directory use secure LDAP binds. You can also avoid this issue by reducing the depth of the OU structure or the length of the OU names. For example, the following distinguished name is 261 characters:

Copy Code

CN=BobKelly,OU=CorporateVicePresidents,OU=CorporateOfficers,OU=ViewOfPugetSoundOffices,OU=TopFloor,OU=Building1557,OU=CorporateCampus,OU=Redmond,OU=Washington,OU=NorthWestern,OU=UnitedStatesOfAmerica,OU=NorthAmerica,DC=BusinessGroup,DC=humongousinsurance,DC=com

If the OU named CorporateVicePresidents is shortened to CVP, the distinguished name for the user account BobKelly is only 242 characters.

Maximum Number of GPOs Applied

There is a limit of 999 Group Policy objects (GPOs) that you can apply to a user account or computer account. This does not mean that the total number of policy settings on the system is limited to 999. Rather, a single user or computer will not be able to process more than 999 GPOs. This limit exists for performance reasons.

Trust Limitations

Trust limitations arise from the number of trusted domain objects (TDOs), the length of trust paths, and the ability of clients to discover available trusts. Limitations that apply include the following:

Kerberos clients can traverse a maximum of 10 trust links to locate a requested resource in another domain. If the trust path between the domains exceeds this limit, the attempt to access the domain fails.

When a client searches out a trust path, the search is limited to the trusts that are established directly with a domain and the trusts that are transitive within a forest.

Previous testing shows that the increased time to complete TDO-related operations, such as authentication across domains, deteriorates performance noticeably if the Active Directory implementation in an organization contains more than 2,400 TDOs.

For more information about trust limitations, see “Practical Limitations of Trusts” in How Domain and Forest Trusts Work (http://go.microsoft.com/fwlink/?LinkID=35356).

Maximum Number of Accounts per LDAP Transaction

When you write scripts or applications that perform LDAP transactions, the recommended limit is to perform no more than 5,000 operations per LDAP transaction. An LDAP transaction is a group of directory operations (such as add, delete, and modify) that are treated as one unit. If your script or application performs more than 5,000 operations in a single LDAP transaction, you are at risk of running into resource limits and an operational time-out. If that happens, all the operations (changes, additions, and modifications) in the transaction are rolled back, which means that you lose all those changes.

As an example, if you are using Active Directory Service Interfaces (ADSI) to write a script, the SetInfo method completes a transaction. For more information about ADSI Methods, see Active Directory Service Interfaces (http://go.microsoft.com/fwlink/?LinkID=4487).

As another example, when you use the System.DirectoryServices (S.DS) namespace in the Microsoft .Net Framework, the DirectoryEntry.CommitChanges method completes an LDAP transaction. For more information about the DirectoryEntry.CommitChanges method, see DirectoryEntry.CommitChanges () (http://go.microsoft.com/fwlink/?LinkId=115220).

Note

Regardless of the method that you use for LDAP transactions, you should plan to send less than 5,000 directory operations in a single transaction. To learn more about the LDAP data structure that commits changes, see LDAPMod (http://go.microsoft.com/fwlink/?LinkId=115221).

Recommended Maximum Number of Users in a Group

For Windows 2000 Active Directory environments, the recommended maximum number of members in a group is 5,000. This recommendation is based on the number of concurrent atomic changes that can be committed in a single database transaction.

Starting with Windows Server 2003, the ability to replicate discrete changes to linked multivalued properties was introduced as a technology called Linked Value Replication (LVR). To enable LVR, you must increase the forest functional level to at least Windows Server 2003 interim. Increasing the forest functional level changes the way that group membership (and other linked multivalued attributes) is stored in the database and replicated between domain controllers. This allows the number of group memberships to exceed the former recommended limit of 5,000 for Windows 2000 or Windows Server 2003 at a forest functional level of Windows 2000.

So far, testing in this area has yet to reveal any new recommended limits to the number of members in a group or any other linked multivalued attribute. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.

Important

Increasing the forest functional level to Windows Server 2003 interim or higher does not modify the way that existing group members are stored or replicated. To do that, you must remove the members that were added to the group before the forest functional level was increased to Windows Server 2003 and then add them back again to the appropriate groups. Any group members that you either add or remove after the forest functional level is increased will be LVR enabled, even if the group contains other members that are not LVR enabled.

For more information about linked attributes, see Linked Attributes (http://go.microsoft.com/fwlink/?LinkId=142909). For more information about the replication process, see How the Active Directory Replication Model Works (http://go.microsoft.com/fwlink/?LinkId=142908).

Recommended Maximum Number of Domains in a Forest

For Windows 2000 Server, the recommended maximum number of domains in a forest is 800. For Windows Server 2003, the recommended maximum number of domains when the forest functional level is set to Windows Server 2003 (also known as forest functional level 2) is 1,200. This restriction is a limitation of multivalued, nonlinked attributes in Windows Server 2003. For more information, see “Maximum Database Record Size” in How the Data Store Works (http://go.microsoft.com/fwlink/?LinkId=134791).

Recommended Maximum Number of Domain Controllers in a Domain

Because the File Replication Service (FRS) is used to replicate SYSVOL in a Windows Server 2003 domain, we recommend a limit of 1,200 domain controllers per domain to ensure reliable recovery of SYSVOL.

If any Active Directory domain in your network is expected to exceed 800 domain controllers and those domain controllers are hosting Active Directory–integrated Domain Name System (DNS) zones, review article 267855 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115222).

For more information about FRS limitations, see the FRS Technical Reference (http://go.microsoft.com/fwlink/?LinkId=115302).

Recommended Maximum Kerberos Settings

The maximum recommended size for a Kerberos ticket is 65,535 bytes, which is configured through the MaxTokenSize REG_DWORD value in the registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa\Kerberos\Parameters). Increasing this value from the default may cause errors, particularly when Web browsers or Web servers are used. For additional information about Kerberos tickets, including error conditions that can occur when Kerberos ticket size limits are set too low or too high, see Additional Resources for Troubleshooting Kerberos (http://go.microsoft.com/fwlink/?LinkId=134740).

MIT Kerberos 5 FAQ

2010-04-28T10:00:00.001-05:00

Account lockout-related event logs

2010-04-07T13:09:00.003-05:00

Event ID
Description
528
A user successfully logged on to a computer. For information about the type of logon, see the Logon Types table below.
529
Logon failure. A logon attempt was made with an unknown user name or a known user name with a bad password.
530
Logon failure. A logon attempt was made, but the user account tried to log on outside of the allowed time.

531
Logon failure. A logon attempt was made using a disabled account.
532
Logon failure. A logon attempt was made using an expired account.
533
Logon failure. A logon attempt was made by a user who is not allowed to log on at this computer.
534
Logon failure. The user attempted to log on with a type that is not allowed.
535
Logon failure. The password for the specified account has expired.
536
Logon failure. The Netlogon service is not active.
537
Logon failure. The logon attempt failed for other reasons.
Note
In some cases, the reason for the logon failure may not be known.
538
The logoff process was completed for a user.
539
Logon failure. The account was locked out at the time the logon attempt was made.
540
A user successfully logged on to a network.
541
Main mode Internet Key Exchange (IKE) authentication was completed between the local computer and the listed peer identity (establishing a security association), or quick mode has established a data channel.
542
A data channel was terminated.
543
Main mode was terminated.
Note
This might occur as a result of the time limit on the security association expiring, policy changes, or peer termination. (The default expiration time for security associations is eight hours.)
544
Main mode authentication failed because the peer did not provide a valid certificate or the signature was not validated.
545
Main mode authentication failed because of a Kerberos failure or a password that is not valid.
546
IKE security association establishment failed because the peer sent a proposal that is not valid. A packet was received that contained data that is not valid.
547
A failure occurred during an IKE handshake.
548
Logon failure. The security identifier (SID) from a trusted domain does not match the account domain SID of the client.
549
Logon failure. All SIDs that correspond to untrusted namespaces were filtered out during an authentication across forests.
550
A denial-of-service attack may have taken place.
551
A user initiated the logoff process.
552
A user successfully logged on to a computer using explicit credentials while already logged on as a different user.
672
An authentication service (AS) ticket was successfully issued and validated.
673
A ticket-granting service (TGS) ticket was granted.
674
A security principal renewed an AS ticket or TGS ticket.
675
Preauthentication failed. This event is generated on a Key Distribution Center (KDC) when a user types in an incorrect password.
676
Authentication ticket request failed. This event is not generated in Windows XP or in the Windows Server 2003 family.
677
A TGS ticket was not granted. This event is not generated in Windows XP or in the Windows Server 2003 family.
678
An account was successfully mapped to a domain account.
681
Logon failure. A domain account logon was attempted. This event is not generated in Windows XP or in the Windows Server 2003 family.
682
A user has reconnected to a disconnected terminal server session.
683
A user disconnected a terminal server session without logging off.
Note
This event is generated when a user is connected to a terminal server session over the network. It appears on the terminal server.
Netlogon Logon Types
When many Netlogon logon events are logged, a logon type is also listed in the event details. The following table describes each logon type.
Table 5 Netlogon Logon Types

Logon type
Logon title
Description
2
Interactive
A user logged on to this computer.
3
Network
A user or computer logged on to this computer from the network.
4
Batch
The batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention.
5
Service
A service was started by the Service Control Manager.
7
Unlock
This workstation was unlocked.
8
NetworkCleartext
A user logged on to this computer from the network. The user's password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext).
9
NewCredentials
A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.
10
RemoteInteractive
A user logged on to this computer remotely using Terminal Services or Remote Desktop.
11
CachedInteractive
A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.

I am now Windows 2008 certified!

2010-03-21T21:42:00.004-05:00

Passed 70-649 two weeks ago, which gave me three certificates:

MCTS: Active Directory
MCTS: Network
MCTS: Application Infrastructure

Two more exams to get my MCITP: Enterprise Admin

Update (Jun 12): Passed 70-747. One more exam (70-680) to get my MCITP:Enterprise Admin
Update (Sep 23): Passed 70-680. Now I am MCITP: Enterprise Admin!

Suggested Thresholds for Essential Counters

2009-11-24T11:06:00.003-05:00

This is excerpted from an MS article for w2k resource kit. Most of the numbers should still be applicable to newer version of OSes.

Resource
Object/Counter
Threshold
Comments

Disk
PhysicalDisk\% Disk Time
90%

Disk
PhysicalDisk\ Disk Reads/sec, PhysicalDisk\Disk
Depends on manufacturer's specifications
Check the disk's specified transfer rate to verify that the logged rate doesn't exceed specifications.(1)

Disk
PhysicalDisk\ Current Disk Queue Length
Number of spindles plus 2
This is an instantaneous counter; observe its value over several intervals. For an average over time, use PhysicalDisk\ Avg. Disk Queue Length

Memory
Memory\Available Bytes
Less than 4 MB
Research memory usage, and then add memory, if needed.

Memory
Memory\Pages/sec
20
Research paging activity, the activity that occurs when data is swapped out of memory and stored on disk when memory is low.

Network
Network Segment\% Net utilization
Depends on network type
For Ethernet networks, the recommended threshold is 30 percent.

Paging File
Paging File\% Usage
99%
Review this value in conjunction with Available Bytes and Pages/sec to understand paging activity on your system.

Processor
Processor\% Processor Time
85%
Isolate the process that is using a high percentage of processor time. Upgrade to a faster processor, or install an additional processor.

Processor
Processor\ Interrupts/sec
Depends on the processor
A dramatic increase in this counter with a corresponding increase in system activity indicates a hardware problem. Identify the network adapter that is causing the interrupts.

Server
Server\Bytes Total/sec
If the sum Bytes for all servers is roughly equal to the maximum transfer rates for your network, you might need to segment the network.

Server
Server\Work Item Shortages
3
If this value reaches the threshold, consider tuning InitWorkItems or MaxWorkItems in the registry.

Server
Server\Pool Paged Peak
Amount of physical RAM
This value indicates the maximum paging file size and the amount of physical memory.

Server
Server Work Queues\Queue Length
4
If this value reaches the threshold, there may be a processor bottleneck. This is an instantaneous counter; observe it over several intervals.

Multiple Processors
System\Processor Queue Length
2
This is an instantaneous counter; observe it over several intervals.

Account Logon vs. Logon/Logoff events in security log

2009-09-22T09:46:00.002-05:00

Ever confused by the "Account Logon" events and "Logon/Logoff" events in your Security Log? Read on.

[Edit: Dec 19, 2011]: This is applicable to Windows 2003. In Windows 2008, "account logon" is changed to "credential validation" to better reflect what it really is.
****************************************
This is a complete copy/paste from MSDN.
****************************************

One of the most common questions that I get about Windows Auditing is, how come you guys were so @#%! stupid that you put in two logon categories?

The answer is actually pretty simple- we're bad at choosing names. "Account Logon" isn't really about logon, it's about credential validation.

Here's the low down on what is the difference between Logon/Logoff and Account Logon events, and how to decipher Account Logon events.

Audit Logon/Logoff generates events for the creation and destruction of logon sessions. These events occur on the machine which was accessed. In the case of an interactive logon, these would be generated on the machine which was logged on to. In the case of network logon, for example, accessing a share, these events would be generated on the machine hosting the resource that was accessed.

Audit Account Logon generates events for credential validation. These events occur on the machine which is authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local machine is authoritative. Since domain accounts are used much more frequently in enterprise environments than local accounts, most of the Account Logon events in a domain environment occur on the domain controllers which are authoriative for the domain accounts. However, these events can occur on any machine, and may occur in conjunction with or on separate machines from logon/logoff events.

Logging on interactively to a workstation, using a domain account, can cause more activity than you might expect on the DC. An interactive logon is pretty complex and involves multiple steps. Typically, from the time you turn on your workstation until the time you are viewing your desktop, the following things happen:

Machine establishes trust with domain: Kerberos AS request (Event 672 on the DC), Kerberos TGS request for AD (DC, 673)
Machine gets policy: Kerberos TGS request for access to Netlogon share on DC [group policy] (DC, 673) (DC, 540, 538, maybe more than once)
User logs on: Kerberos AS request (DC, 672), Kerberos TGS request for AD (DC, 673), Logon session created (workstation, 528, 576)
User gets policy: Kerberos TGS request for DC\Netlogon [logon scripts, group policy] (DC, 673), Network logon (DC, 540, 538, usually 2-3 rounds)
In Account Logon failures for Kerberos, the KDC has to generate an AS reply with an RFC 1510 error. Since RFC 1510 error codes don't contemplate Windows-specific errors, and we have to return Kerberos-specific errors in Kerberos AS request failure replies, we had to map Windows error conditions to kerberos error codes. The error code mappings are described in the Kerberos Troubleshooting document that is available on Microsoft.com: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

Here are some questions that you might have about Account Logon events:

Q: Why do you only have the IP address in the Account Logon event, and not the computer name?
A: There are three reasons:

There is no secure method for the KDC to get the remote machine's name at the current time. If the client provides the name (as in NTLM), then it's not trustworthy and can be spoofed. There are Unix-based hacking tools which spoof workstation name in NTLM auth requests.
DNS and NetBIOS reverse lookup are not secure and are not reliable- if we tried this, we'd have a high incidence of incorrect or missing information, and hurt performance.
Even if we chose to do add the name anyway, when we could, there's no field for us to use to carry it in Kerberos AS REQ & TGS REQ messages- we'd have to overload some other field, and run a high risk of loss of compatibility with MIT's reference implementation.
Q: How do I correlate the Account Logon event on a DC with the Logon/Logoff event on the machine which was accessed?
A: Easy! The Account Logon event and the Logon/Logoff event both contain a field called a Logon GUID, starting in Windows Server 2003. Just compare the GUIDs- if they match, it's the same Kerberos ticket. Unfortunately this only works for Kerberos; other Logon events contain a GUID that is all zeroes.

Q: Is there such a thing as an Account Logoff event?
A: No. The DC is only aware of logons, not logoffs (there's no possible way to force a machine to contact a DC when logging off- consider crashes, etc.)

Q: I just want to monitor my DC's logs. Is that good enough?
A: Well, the DC has a distorted view of logon as mentioned above. Also, the DC only knows where the logon request came from most recently. Consider using IIS- the logon request originates at a browser somewhere on the internet. IIS receives the request and then sends a logon request to the DC. From the DC's point of view, the source of the logon is IIS. If you only collect the DC's logs, you'll miss the detail of where the request came from. This is true for any network service- RPC, file sharing, remote desktop, etc. Also, the DC doesn't have enough information to answer "how long was the user logged on". However there is one really interesting piece of information in DC logs. In event 673 (Kerberos Service Ticket granted), the service name is listed. This is the most detail that the DC can provide, on what the user was logging on for.

Backup and restore TCP/IP stack config using command line

2009-09-03T15:45:00.001-05:00

netsh -c interface dump > ipconfig.txt
netsh -f ipconfig.txt

Windows 2008 Self-Learning Notes #1

2009-04-22T09:28:00.001-05:00

- It has different Password Policies now to different group of users, which a good thing. MS gives it a fancy name PSO instead of continues using GPO.
- AD now has a new mode called Stop Mode, which can be handy at times
- RODC is fit for less-secure branch offices. Pay attention to what are cached, and how password is replicated
- So called AD Snapshots is probably transformed from Mark Russinovich (former Sysinternals). It sounds exciting but it's actual use might be limited in big corporations. It takes long time to make a snapshot and occupies too much space. You must have a dedicated server/storage to take/host the snapshots to make it useful.
- AD change history logging is finally in place.

- On top of Terminal Service, now we have RemoteApp, which makes an app running on server looks like running locally.
- Hyper-V needs hardware support, which I don't have. It is just MS' free offer to compete with VMware.
- Offline VHD manipulation is possible in Windows 2008. This will be useful in some DR/troubleshooting scenarios.
- In Windows Server 2008, Group Policy is treated as its own component with a new Group Policy Service, a stand-alone service that runs under the Svchost process for the purpose of reading and applying Group Policy. The new service includes changes with event reporting. Group Policy event messages, previously appearing in the application log, now appear in the system log. The event viewer lists these new messages with an event source of Microsoft-Windows-GroupPolicy. The Group Policy Operational log replaces previous userenv logging. The operational event log provides improved event messages specific to Group Policy processing.

Change TSM client password on cluster

2009-01-28T15:12:00.002-05:00

Or when there are more than one scheduler services.

On the active node, open command prompt
>dsmc -optfile="the opt file that you want to change"
>q se
>set password

Failover to second node, do the same.

Replacing a cert without losing existing cert in IIS

2009-01-15T10:45:00.002-05:00

http://support.microsoft.com/kb/295281

Recently I ran into a problem when I tried to generate a CSR. The current cert in use was from VeriSign and we wanted to switch to thawte. The problem was that the option "Replace current cert" was grayed out because existing cert was still valid. The above KB is the perfect workaround.