In just about every AD LDS instance I set up for a customer, there is some attribute within msDS-Other-Settings that I need to modify. The attribute, msDS-Other-Settings, is found within the Directory Service container for the AD LDS instance. More specifically, it is found by connecting to the Configuration Naming Context of your instance and going to CN=Services -> Windows NT -> Directory Service:
To access the msDS-Other-Settings attribute, you need only go to the properties for the Directory Service container within ADSI Edit. Once you are in the properties dialog screen for the Directory Service container, you would scroll down to the msDS-Other-Settings attribute and click “Edit” to see all of its sub-attributes. The sub attributes are noted in the following screen shot:
I will now give a detailed break down of each sub-attribute found under msDS-Other-Settings.
- ADAMAllowADAMSecurityPrincipalsInConfigPartition – By default, the value for this attribute is “0″. Setting this value to “1″ will allow users to be created in the AD LDS configuration partition. Why would you want to create users in the configuration partition? If you want any AD LDS users to be administrators of your instance, setting this value to “1″ will achieve just that.
- ADAMDisableLogonAuditing – This value is also “0″ by default”. Setting the value to “1″ will, understandably, disable any audits related to the logon of a security principal. Since it is a default of “0″, audit logging will occur whenever a security principal authenticates to the server.
- ADAMDisablePasswordPolicies – This is a value I mentioned in my previous AD LDS 101 post. By default, this value is set to “0″ which indicates that the password policies of either the domain or the local system will be applied to the AD LDS instance. I had a customer in Long Island who decided to enable this option since the passwords of the service level accounts for the product I installed were expiring on an interval consistent with their domain password policy. This impacted the overall uptime/stability of the application and resulted in this attribute being set to a value of “1″. Now the password policies are ignored for local AD LDS users. Fairly helpful when you cannot change the overall domain policy.
- ADAMDisableSPNRegistration – This is a particularly fun attribute when you read about it on MSDN. Microsoft states the following about this attribute:
“When ADAMDisableSPNRegistration equals 1, a DC running as AD LDS does not register its SPNs on the servicePrincipalName of the computerobject as described in [MS-DRDM] section 2.2.2. When ADAMDisableSPNRegistration equals 0, a DC running as AD LDS performs SPN registration as described in that document. If ADAMDisableSPNRegistration is not explicitly specified, it defaults to 0.”
If you are thinking, “Uh, great, but what does that all mean, Microsoft?”, you are not alone. I remember looking at this and thinking, “Can you just put it in layman’s terms for those of us just learning about AD LDS?” They have yet to respond to my request, so I shall do my best to explain it for them.
What they intended to say was that, if the value for this attribute is “1″, any domain controller (DC) running as AD LDS will not register it Service Principal Name(s) in the computer object for said DC. The SPN(s) are names for service instances running on a host. There can be many SPNs for a given service provided there are many names that point back to said service (eg. hostname, fqdn, etc). I have never had a need to modify this and cannot think of a time when I would.
- ADAMLastLogonTimestampWindow – This is the frequency that AD LDS writes to lastLogonTimestamp when an AD LDS security principal authenticates to the server. The default value for this attribute is “7″. This value is expressed in days. There is a calculation that is done using the comparison of the lastLogonTimestamp attribute value against the ADAMLastLogonTimeStampWindow. If the comparison of the value of the current logon time by a security principal and the value of the lastLogonTimestamp prove to be longer than the value for ADAMLastLogonTimestampWindow, the lastLogonTimestamp value will be updated.
- DisableVLVSupport – By default in AD LDS, VLV support is not disabled (value equals “0″). VLV (Virtual List View) is the ability of the server to supply on-demand data for a large list of information that would normally be viewed in a GUI, scroll list. VLV makes it possible for the server to display only the data that is currently being viewed in the list, thus not requiring all data to be downloaded at one time. VLV is a very efficient method of providing on-demand data in lists so as to not overwhelm the data-retrieval process or memory. This attribute will determine whether VLV for LDAP searches will be supported. I would recommend keeping this enabled at its default value.
- DynamicObjectDefaultTTL – As a default, the value for this attribute is 86400 seconds (1 day~). It is fairly self-explanatory that this determines the time to live (entryTTL) of new dynamic objects within AD LDS.
- DynamicObjectMinTTL – Similar to the previous attribute, this is the minimum time to live (entryTTL) for new dynamic objects in AD LDS. The default value for this attribute is 900 seconds (15 minutes).
- MaxReferrals – This is the maximum number of referrals AD LDS will support. A referral is where an AD LDS instance refers a client query to another instance. A reason for this might be when a client is requesting data that is in the overall configuration set for the domain, but not in the AD LDS instance. The instance would refer the query to the configuration set where the data resides to complete the query. The default value for this attribute is “3″.
- ReferralRefreshInterval – This is the interval at which the referral information is updated. The referral information is housed in the crossRef object. The default value for this attribute is 5 minutes.
- RequireSecureProxyBind – Whenever I am at a prospective customer site doing an eval install, I will set this attribute value from its default of “1″ to “0″. Given, setting this value to “0″ is not secure, nor is it recommended for a production environment. However, when you are doing an eval install of a product and have a very short time to get things working, setting this attribute to a less secure value can mean the difference between having the application up and running in an hour vs an undetermined wait while the sysadmin hunts down the CA guy to get the SLDAP cert issued. This only indirectly defines what this attribute does. This attribute is important when you are using userProxy as the object class for users that have been synchronized into your AD LDS instance. When a user is of the userProxy class, any authentication for said use is proxied back to the originating DC for a credential check. If you set this attribute to “1″ (the default value), then you will need to user SLDAP in order to get proxy authentication working. If you set the attribute value to “0″, this will eliminate the requirement for SLDAP and send the proxied credentials in clear text back to the originating DC.
Note: In production, if you ever set this attribute value to “0″, I would highly recommend moving it back to the default value of “1″ to require SLDAP.
- RequireSecureSimpleBind – This is similar to RequireSecureProxyBind. The main differences are that its default value is set to “0″ (no SLDAP) and it is for a simple bind vs a proxy bind. Simple binds simply authenticate to the local AD LDS instance vs a proxy bind which sends the credential check back to the originating domain controller.
- SelfReferralsOnly – Again, this attribute is very literal in its function; Either it only refers to itself for referrals (value is equal to “1″) or it allows normal referrals to other instances in the configuration set (value is equal to “0″ – default).
And this is your detailed look at the msDS-Other-Settings attribute. I have not used all of these sub-attributes, but do see some that might come in handy in the future. More than anything, though, I am glad to know what each attribute does and how it could potentially be used in any given situation. My hope is that this is a good foundation for you to leverage in your continuing work with AD LDS.
