XADM: How the Active Directory Connector Stores Passwords (253830)
The information in this article applies to:
- Microsoft Exchange 2000 Server
- Microsoft Exchange Server 5.5 SP3
- the operating system: Microsoft Windows 2000
This article was previously published under Q253830 IMPORTANT: This article contains information about modifying the registry. Before you
modify the registry, make sure to back it up and make sure that you understand how to restore
the registry if a problem occurs. For information about how to back up, restore, and edit the
registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry
SUMMARY
When a new connection agreement is created on an Active Directory Connector (ADC), a username and password pair (credentials) must be supplied for each server that the ADC is going to communicate with. This means credentials must be supplied for the Exchange Server 5.5 computer and also for Active Directory. The ADC must store these passwords in a secure manner to avoid compromising security.
This article discusses the process the ADC uses to securely store these passwords and the purpose of the timestamp on the credentials.
MORE INFORMATIONThe Process of Storing Passwords
To securely store the passwords that are used to connect to Exchange Server 5.5 and Active Directory, the ADC stores the password in link state algorithm (LSA) Global Secrets. The LSA is a storage location in Windows that is used to store very sensitive information such as passwords.
The ADC goes through the following process when new a Connection Agreement is created:
- The ADC Microsoft Management Console (MMC) snap-in makes a secure remote procedure call (RPC) to the ADC and asks it to store the pair of credentials.
- The RPC request is sent to the ADC server that the Connection Agreement is created on because the LSA Global Secrets is stored on the individual computer and it is not replicated between member servers. The LSA Global Secrets is replicated between domain controllers, but the ADC does not depend on this, so it uniformly sets the password on the server that is responsible for the Connection Agreement.
- The ADC verifies that the person who is using the ADC snap-in has the right to store this information. This verification is done by checking to see if the user has generic write access on the following object in Active Directory:
CN=Active Directory Connector ServerName, CN=Exchange Settings, CN=ServerName, CN=Servers, CN=Default-First-Site-Name, CN=Sites, CN=Configuration, DC=DomainName - After the security check is passed, the ADC stores the pair of credentials with a timestamp to the LSA.
Only the ADC service can read the password back because the only RPC interface that is exposed sets the password; it does not read it. Therefore, when an attempt is made to change the Import or Export container, or re-home a Connection Agreement, the ADC displays a prompt to enter the password for that server.
The passwords are NOT stored on a per-Connection Agreement basis. For example, suppose two Connection Agreements share the same credentials. If you change the password in one Connection Agreement, it will also be used by the other one. This saves space in the Global Secrets, and saves time when the password of a service account must be changed. You only need to update the password once for each ADC server.
The Purpose of Storing a Timestamp with the Passwords
When the ADC stores credentials in the LSA, it also stores a timestamp along with the credentials.
When a password is set or reset for a credential, the timestamp is updated with the current time. Also, every time the ADC reads the password, if the timestamp is older than seven days, the timestamp is updated with the current time.
This timestamp is used for two reasons:
- The LSA has very limited space, of which the ADC is only allocated 64 kilobytes. So, if the ADC starts running out of space in the LSA, the oldest non-used credential will be removed.
-and-
-
The passwords stored in the LSA expire when the timestamp is older than the expiration limit.
The following table explains the expiration limits:
|
Fewer than 16 | 180 days | More than or equal to 16 and fewer than 32 | 120 days | More than or equal to 32 and fewer than 128 | 90 days | More than 128 | 60 days |
As noted, any credential or password that has not been used for the last 180 days is removed. This is the case if a Connection Agreement is created, and the replication schedule is set to "Never." After 180 days, the schedule is set to "Always" or "Scheduled." In this case, the Connection Agreement will not work because the password has expired and is removed from the LSA Global Secrets.
You can change the expiration limit by using the following registry key: WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you can solve
problems that result from using Registry Editor incorrectly. Use Registry Editor at your own
risk. - Start Registry Editor (Regedt32.exe).
- Locate the following key in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSADC\Parameters - On the Edit menu, click Add Value, and then add the following registry value:
Value Name: Password Expiration Data Type: REG_DWORD Value: Number of days
- Quit Registry Editor.
The value is the minimum number of days that a credential or password will stay in the LSA Global Secrets without expiring.
Notice that if you have a Connection Agreement that is set to run on "Scheduled" or "Always," its password will never expire because the timestamp is updated every seven days when the ADC reads the password to replicate that Connection Agreement.
Modification Type: | Minor | Last Reviewed: | 4/21/2005 |
---|
Keywords: | kbhowto KB253830 |
---|
|