Microsoft Office 2010 Service Pack 1 has now been officially released by Microsoft as of June 28th 2011.
The official KB for this release is 2460049
Download the 32bit version from here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=9D2E1282-8B69-418B-AFA0-9F61239EC8BE
Download the 64bit version from here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=E9F3C2D0-C321-4910-A4CE-B2F294B42D65
Tuesday, June 28, 2011
Wednesday, June 22, 2011
WARNING: An unexpected error has occurred and a Watson dump is being generated: Failed to find the mailbox.
In this post I'm going to address a very common problem many new Exchange 2010 Administrators face.
When running commands such as Test-OutlookWebServices on an Exchange 2010 CAS you will receive the following error:
[PS] C:\>Test-OutlookWebServices
WARNING: An unexpected error has occurred and a Watson dump is being generated: Failed to find the mailbox. Mailbox ='extest_0f9a03d82a6d4@destination.local'.
Failed to find the mailbox. Mailbox = 'extest_0f9a03d82a6d4@destination.local'.
+ CategoryInfo : NotSpecified: (:) [Test-OutlookWebServices], MailboxNotFoundException
+ FullyQualifiedErrorId : Microsoft.Exchange.Monitoring.MailboxNotFoundException,Microsoft.Exchange.Management.SystemConfigurationTasks.TestOutlookWebServicesTask
This is probally the first time you have run the Test command isn't it? In Exchange 2010 you need a test mailbox to perform tests with. This can be created using the new-TestCasConnectivityUser.ps1 powershell script Microsoft provides us with Exchange 2010.
All you need to do is navigate to the Scripts directory:
C:\Program Files\Microsoft\Exchange Server\V14\Scripts
Then run .\new-TestCasConnectivityUser.ps1
Provide the test mailbox a password when prompted...
Easy?
When running commands such as Test-OutlookWebServices on an Exchange 2010 CAS you will receive the following error:
[PS] C:\>Test-OutlookWebServices
WARNING: An unexpected error has occurred and a Watson dump is being generated: Failed to find the mailbox. Mailbox ='extest_0f9a03d82a6d4@destination.local'.
Failed to find the mailbox. Mailbox = 'extest_0f9a03d82a6d4@destination.local'.
+ CategoryInfo : NotSpecified: (:) [Test-OutlookWebServices], MailboxNotFoundException
+ FullyQualifiedErrorId : Microsoft.Exchange.Monitoring.MailboxNotFoundException,Microsoft.Exchange.Management.SystemConfigurationTasks.TestOutlookWebServicesTask
This is probally the first time you have run the Test command isn't it? In Exchange 2010 you need a test mailbox to perform tests with. This can be created using the new-TestCasConnectivityUser.ps1 powershell script Microsoft provides us with Exchange 2010.
All you need to do is navigate to the Scripts directory:
C:\Program Files\Microsoft\Exchange Server\V14\Scripts
Then run .\new-TestCasConnectivityUser.ps1
Provide the test mailbox a password when prompted...
Easy?
Monday, June 20, 2011
Error 49: ldap_simple_bind_s() failed: Invalid Credentials
I have setup a Windows Server 2008 R2 server running LDS. I have an LDS Instance running on 10001 (LDAP) and 20001 (LDAPS).
I added a user account using the following:
dn: CN=testaccount,CN=Users,DC=domain,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: testaccount
cn: testaccount
displayName: My Test Account
userPassword: Passw0rd
Note: As the requirement for special formatting of unicodePwd has been lifted Microsoft has placed a default requirement to ensure all password operations are done through LDAPS instead of LDAP. To allow password operations through LDAP please see:
http://clintboessen.blogspot.com/2011/06/0x2077-illegal-modify-operation-some.html
When I attempt to bind to this account using ldp.exe using "Simple Bind" over LDAP (not secure LDAP) using the following credentials I get an error:
username: CN=testaccount,CN=Users,DC=domain,DC=ADAM
password: Passw0rd
-----------
res = ldap_simple_bind_s(ld, 'CN=testaccount,CN=Users,DC=domain,DC=ADAM',); // v.3
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 2030, v1db0
Error 0x8009030C The logon attempt failed
-----------
There were three things I needed to change to get this working.
Problem 1
I read from multiple places on the internet that by default when you associate a password to an account - the account is disabled. I also know that this error can be related to the user account being disabled - please see:
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/44d29c43-4203-400a-bff4-c488da5c5f57/
However the attribute which sets the account password to disabled "msDS-UserAccountDisabled" was not associated with the user class object in the schema. AD LDS has a series of attributes to control a user account for items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password etc. For a list of these attributes please see:
http://msdn.microsoft.com/en-us/library/aa772124.aspx
Note: Active Directory does not have these attributes, instead all these values are associated with an attribute called userAccountControl. This attribute has an integer set to it.. 512 is a normal account. To disable an account add a value of 2. In decimal, this is 514 (2 + 512). For more information on how this works in Active Directory please see: http://support.microsoft.com/kb/305144
To associate these attributes with the user class object you need to connect to the LDS Instance using the Active Directory Schema Console. If Active Directory Schema does not exist in your MMC snap-in list register it using "regsrv32 schmmgmt.dll" from command line.
Note: When connecting to your LDS Instance you cannot use localhost or it will fail. You must use the IP address of the LDS Instance. This is due to a code error in the Active Directory schema console, please see:
http://clintboessen.blogspot.com/2011/06/lds-active-directory-schema-status.html
Once connected to your LDS Instance in Active Directory Schema MMC snap-in go to the properties of the user class object and click the attributes tab.
As you see none of the msDS-User type class objects exist. Go ahead and add the following attributes:
- ms-DS-UserAccountAutoLocked
- msDS-UserAccountDisabled
- msDS-UserDontExpirePassword
- ms-DS-UserEncryptedTextPassword
- msDS-UserPasswordExpired
- ms-DS-UserPasswordNotRequired
After the attribute is added, restart your LDS Instance service and connect to the application partition in ADSIEdit containing your user account. Set the msDS-UserAccountDisabled to FALSE.
Problem 2
You must allow Simple Bind requests to an AD LDS Instance over standard LDAP. To do this connect to the configuration partition on your LDS Instance using ADSIEdit. My instance is listening on TCP 10001.
Navigate to:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID}
Open the properties of Directory Service. Open the multivalued attribute msDS-Other-Settings. Ensure RequireSecureSimpleBind is set to 0. This will ensure that both LDAP and LDAPS connections are allowed to bind authentication to the LDS Instance.
Note: RequireSecureProxyBind is for userProxy class objects which perform bind proxy redirection.
Problem 3
The third problem related to the following TechNet article:
http://technet.microsoft.com/en-us/library/cc732460.aspx
This article states:
AD LDS does not include any default security principals. However, AD LDS does provide importable schema extensions that you can use to create users in AD LDS. Users that are created from these user classes can be used as security principals. In addition, you can make any object class in the AD LDS schema a security principal by adding the msDS-bindableobject auxiliary class and the unicodePwd attribute to the schema definition of an object class. Each AD LDS security principal must be assigned an account and password, which AD LDS uses for authentication.
To do this open up ADSIEdit and connect to the Schema partition of your LDS Instance.
Navigate to the CN=User class object in ADSIEdit under the Schema partition and open its properties.
As you see the msDS-bindableobject auxiliary class does not exist.
Add it to the list and click OK.
Restart the LDS Instance under the services MMC console.
Reset the user's password by connecting to the appropriate application partition in ADSIEdit, right clicking on the user and clicking Reset Password.
I was now ale to perform a simple bind to my LDS Instance using a LDS user account.
-----------
res = ldap_simple_bind_s(ld, 'CN=SVCLDAPQuery,CN=Users,DC=domain,DC=ADAM',); // v.3
Authenticated as: 'CN=SVCLDAPQuery,CN=Users,DC=domain,DC=ADAM'.
-----------
You can also do this using an LDIF file:
dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: Modify
add: auxiliaryClass
auxiliaryClass: msDS-BindableObject
-
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
imported using (ignore line wraps below)
ldifde -i -f -s : -c
"CN=Schema,CN=Configuration,DC=X" #schemaNamingContext
Thanks to Lee Fight (Directory Services MVP) who assisted me in getting this working!
I added a user account using the following:
dn: CN=testaccount,CN=Users,DC=domain,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: testaccount
cn: testaccount
displayName: My Test Account
userPassword: Passw0rd
Note: As the requirement for special formatting of unicodePwd has been lifted Microsoft has placed a default requirement to ensure all password operations are done through LDAPS instead of LDAP. To allow password operations through LDAP please see:
http://clintboessen.blogspot.com/2011/06/0x2077-illegal-modify-operation-some.html
When I attempt to bind to this account using ldp.exe using "Simple Bind" over LDAP (not secure LDAP) using the following credentials I get an error:
username: CN=testaccount,CN=Users,DC=domain,DC=ADAM
password: Passw0rd
-----------
res = ldap_simple_bind_s(ld, 'CN=testaccount,CN=Users,DC=domain,DC=ADAM',
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 2030, v1db0
Error 0x8009030C The logon attempt failed
-----------
There were three things I needed to change to get this working.
Problem 1
I read from multiple places on the internet that by default when you associate a password to an account - the account is disabled. I also know that this error can be related to the user account being disabled - please see:
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/44d29c43-4203-400a-bff4-c488da5c5f57/
However the attribute which sets the account password to disabled "msDS-UserAccountDisabled" was not associated with the user class object in the schema. AD LDS has a series of attributes to control a user account for items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password etc. For a list of these attributes please see:
http://msdn.microsoft.com/en-us/library/aa772124.aspx
Note: Active Directory does not have these attributes, instead all these values are associated with an attribute called userAccountControl. This attribute has an integer set to it.. 512 is a normal account. To disable an account add a value of 2. In decimal, this is 514 (2 + 512). For more information on how this works in Active Directory please see: http://support.microsoft.com/kb/305144
To associate these attributes with the user class object you need to connect to the LDS Instance using the Active Directory Schema Console. If Active Directory Schema does not exist in your MMC snap-in list register it using "regsrv32 schmmgmt.dll" from command line.
Note: When connecting to your LDS Instance you cannot use localhost or it will fail. You must use the IP address of the LDS Instance. This is due to a code error in the Active Directory schema console, please see:
http://clintboessen.blogspot.com/2011/06/lds-active-directory-schema-status.html
Once connected to your LDS Instance in Active Directory Schema MMC snap-in go to the properties of the user class object and click the attributes tab.
As you see none of the msDS-User type class objects exist. Go ahead and add the following attributes:
- ms-DS-UserAccountAutoLocked
- msDS-UserAccountDisabled
- msDS-UserDontExpirePassword
- ms-DS-UserEncryptedTextPassword
- msDS-UserPasswordExpired
- ms-DS-UserPasswordNotRequired
After the attribute is added, restart your LDS Instance service and connect to the application partition in ADSIEdit containing your user account. Set the msDS-UserAccountDisabled to FALSE.
Problem 2
You must allow Simple Bind requests to an AD LDS Instance over standard LDAP. To do this connect to the configuration partition on your LDS Instance using ADSIEdit. My instance is listening on TCP 10001.
Navigate to:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID}
Open the properties of Directory Service. Open the multivalued attribute msDS-Other-Settings. Ensure RequireSecureSimpleBind is set to 0. This will ensure that both LDAP and LDAPS connections are allowed to bind authentication to the LDS Instance.
Note: RequireSecureProxyBind is for userProxy class objects which perform bind proxy redirection.
Problem 3
The third problem related to the following TechNet article:
http://technet.microsoft.com/en-us/library/cc732460.aspx
This article states:
AD LDS does not include any default security principals. However, AD LDS does provide importable schema extensions that you can use to create users in AD LDS. Users that are created from these user classes can be used as security principals. In addition, you can make any object class in the AD LDS schema a security principal by adding the msDS-bindableobject auxiliary class and the unicodePwd attribute to the schema definition of an object class. Each AD LDS security principal must be assigned an account and password, which AD LDS uses for authentication.
To do this open up ADSIEdit and connect to the Schema partition of your LDS Instance.
Navigate to the CN=User class object in ADSIEdit under the Schema partition and open its properties.
As you see the msDS-bindableobject auxiliary class does not exist.
Add it to the list and click OK.
Restart the LDS Instance under the services MMC console.
Reset the user's password by connecting to the appropriate application partition in ADSIEdit, right clicking on the user and clicking Reset Password.
I was now ale to perform a simple bind to my LDS Instance using a LDS user account.
-----------
res = ldap_simple_bind_s(ld, 'CN=SVCLDAPQuery,CN=Users,DC=domain,DC=ADAM',); // v.3
Authenticated as: 'CN=SVCLDAPQuery,CN=Users,DC=domain,DC=ADAM'.
-----------
You can also do this using an LDIF file:
dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: Modify
add: auxiliaryClass
auxiliaryClass: msDS-BindableObject
-
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
imported using (ignore line wraps below)
ldifde -i -f
"CN=Schema,CN=Configuration,DC=X" #schemaNamingContext
Thanks to Lee Fight (Directory Services MVP) who assisted me in getting this working!
Wednesday, June 15, 2011
Active Directory userAccountControl and LDS
Active Directory user accounts have an attribute called userAccountControl which is used to control items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password etc. This is determined by an integer value... based on the value the system knows which options are enabled and which are disabled. The value 512 is the base value for all normal user accounts. To understand all integers that make this attribute work please refer to the following KB article.
http://support.microsoft.com/kb/305144
AD LDS (ADAM) does not support the userAccountControl attribute. Instead, AD LDS uses several individual attributes to hold the information that is contained in the flags of the userAccountControl attribute.
For a list of these attributes please refer to the following MSDN article:
http://msdn.microsoft.com/en-us/library/aa772124.aspx
Any userAccountControl flags that are not listed below are not supported by AD LDS.
http://support.microsoft.com/kb/305144
AD LDS (ADAM) does not support the userAccountControl attribute. Instead, AD LDS uses several individual attributes to hold the information that is contained in the flags of the userAccountControl attribute.
For a list of these attributes please refer to the following MSDN article:
http://msdn.microsoft.com/en-us/library/aa772124.aspx
Any userAccountControl flags that are not listed below are not supported by AD LDS.
0x2081 Multiple values were specified for an attribute
I'm trying to import the following LDIF file into an LDS Instance using LDIFDE.
dn: CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: SVCLDAPQuery
cn: Service Now LDAP Query
displayName: Service Now LDAP Query
userPassword: Passw0rd
I am performing the import with the following command:
ldifde -i -f SVCLDAPQuery.ldf -s localhost:10001
This command throws out the following errors:
Connecting to "localhost:10001"
Logging in as current user using SSPI
Importing directory from file "SVCLDAPQuery.ldf"
Loading entries.
Add error on entry starting on line 1: Invalid DN Syntax
The server side error is: 0x2081 Multiple values were specified for an attribute that can have only one value.
The extended server error is:
00002081: NameErr: DSID-03050C42, problem 2003 (BAD_ATT_SYNTAX), data 0, best match of:
'CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM'
0 entries modified successfully.
An error has occurred in the program
No log files were written. In order to generate a log file, please
specify the log file path via the -j option.
This occured because the "cn" attribute did not match the first part of the "distinguishedName" attribute. If we change this to:
dn: CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: SVCLDAPQuery
cn: SVCLDAPQuery
displayName: Service Now LDAP Query
userPassword: Passw0rd
The import will work correctly:
Please also see this problem as it is related:
http://clintboessen.blogspot.com/2011/06/0x2077-illegal-modify-operation-some.html
dn: CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: SVCLDAPQuery
cn: Service Now LDAP Query
displayName: Service Now LDAP Query
userPassword: Passw0rd
I am performing the import with the following command:
ldifde -i -f SVCLDAPQuery.ldf -s localhost:10001
This command throws out the following errors:
Connecting to "localhost:10001"
Logging in as current user using SSPI
Importing directory from file "SVCLDAPQuery.ldf"
Loading entries.
Add error on entry starting on line 1: Invalid DN Syntax
The server side error is: 0x2081 Multiple values were specified for an attribute that can have only one value.
The extended server error is:
00002081: NameErr: DSID-03050C42, problem 2003 (BAD_ATT_SYNTAX), data 0, best match of:
'CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM'
0 entries modified successfully.
An error has occurred in the program
No log files were written. In order to generate a log file, please
specify the log file path via the -j option.
This occured because the "cn" attribute did not match the first part of the "distinguishedName" attribute. If we change this to:
dn: CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: SVCLDAPQuery
cn: SVCLDAPQuery
displayName: Service Now LDAP Query
userPassword: Passw0rd
The import will work correctly:
Please also see this problem as it is related:
http://clintboessen.blogspot.com/2011/06/0x2077-illegal-modify-operation-some.html
0x2077 Illegal modify operation. Some aspect of the modification is not permitted.
I'm trying to import the following LDIF file into an LDS Instance using LDIFDE.
dn: CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: SVCLDAPQuery
userPassword: Passw0rd
Note: For ADAM, Microsoft enabled the userPassword attribute to function as a write-alias for unicodePwd and removed the requirement for the special formatting unicodePwd required. This allows your LDIF files to have clear-text passwords specified.
I am performing the import with the following command:
ldifde -i -f SVCLDAPQuery.ldf -s localhost:10001
This command throws out the following errors:
Connecting to "localhost:10001"
Logging in as current user using SSPI
Importing directory from file "SVCLDAPQuery.ldf"
Loading entries.
Add error on entry starting on line 1: Operations Error
The server side error is: 0x2077 Illegal modify operation. Some aspect of the modification is not permitted.
The extended server error is:
00002077: SvcErr: DSID-033807B5, problem 5012 (DIR_ERROR), data 8237
0 entries modified successfully.
An error has occurred in the program
No log files were written. In order to generate a log file, please
specify the log file path via the -j option.
As the requirement for special formatting of unicodePwd has been lifted Microsoft has placed a default requirement to ensure all password operations are done through LDAPS instead of LDAP. This is why it will not import the password!
To lift this requirement make the following change to the configuration partition of the instance:
Navigate to CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID of the ADAM}
Edit dSHeuristics attribute and set value to 0000000001001
Now you can perform password operations without requiring LDAPS.
Please also see this problem as it is related:
http://clintboessen.blogspot.com/2011/06/0x2081-multiple-values-were-specified.html
dn: CN=SVCLDAPQuery,CN=Users,DC=testinstance,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: SVCLDAPQuery
userPassword: Passw0rd
Note: For ADAM, Microsoft enabled the userPassword attribute to function as a write-alias for unicodePwd and removed the requirement for the special formatting unicodePwd required. This allows your LDIF files to have clear-text passwords specified.
I am performing the import with the following command:
ldifde -i -f SVCLDAPQuery.ldf -s localhost:10001
This command throws out the following errors:
Connecting to "localhost:10001"
Logging in as current user using SSPI
Importing directory from file "SVCLDAPQuery.ldf"
Loading entries.
Add error on entry starting on line 1: Operations Error
The server side error is: 0x2077 Illegal modify operation. Some aspect of the modification is not permitted.
The extended server error is:
00002077: SvcErr: DSID-033807B5, problem 5012 (DIR_ERROR), data 8237
0 entries modified successfully.
An error has occurred in the program
No log files were written. In order to generate a log file, please
specify the log file path via the -j option.
As the requirement for special formatting of unicodePwd has been lifted Microsoft has placed a default requirement to ensure all password operations are done through LDAPS instead of LDAP. This is why it will not import the password!
To lift this requirement make the following change to the configuration partition of the instance:
Navigate to CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID of the ADAM}
Edit dSHeuristics attribute and set value to 0000000001001
Now you can perform password operations without requiring LDAPS.
Please also see this problem as it is related:
http://clintboessen.blogspot.com/2011/06/0x2081-multiple-values-were-specified.html
Monday, June 13, 2011
Ldap error occured. ldap_add_sW: Object Class Violation
I am performing ADAMSync from an Active Directory domain to an LDS Instance. My AD Domain Partition is called DC=Domain,DC=Local. My LDS Instance also has the same distinguished name of DC=Domain,DC=Local. When Syncing the following error is experienced:
Processing Entry: Page 18, Frame 1, Entry 48, Count 1, USN 0
Processing source entry
Processing in-scope entry 08080633da0dfe4f8b46508f00f2708f.
Adding target object CN=JoeBlow,OU=Disabled accounts,OU=IS Users,OU=IS,DC=Domain,DC=Local.
Adding attributes: sourceobjectguid, sn, title, description, physicalDeliveryOfficeName, telephoneNumber, givenName, instanceType, department, company, objectSid, sAMAccountName, lastagedchange, objectclass,
Ldap error occured. ldap_add_sW: Object Class Violation.
Extended Info: 0000207D: UpdErr: DSID-0315121C, problem 6002 (OBJ_CLASS_VIOLATION), data 19
.
Ldap error occured. ldap_add_sW: Object Class Violation.
Extended Info: 0000207D: UpdErr: DSID-0315121C, problem 6002 (OBJ_CLASS_VIOLATION), data 19
.
************
************
************ A fatal error occured in the program while processing entry
************ GUID=08080633da0dfe4f8b46508f00f2708f
************ The error will be ignored at user request. Continuing...
************
************
Below I will explain how to resolve this. I am syncing all User Objects from Active Directory to userProxy objects in LDS. This is required for single sign on (SSO). userProxy objects forward authentication bind requests to domain controllers which process the authentication request, pass it back to LDS then to the client.
To understand this in more detail please read my following blog post on the userProxy class:
http://clintboessen.blogspot.com/2011/04/userproxy-class-and-adam-lds.html
Here is a copy of my XML configuration file I installed into ADAMSync:
<?xml version="1.0"?>
<doc>
<configuration>
<!-- Sync File Description -->
<description>ADAMSync Configuration</description>
<security-mode>object</security-mode>
<!-- source-ad-name = fqdn of the domain controller -->
<source-ad-name>domaincontroller.domain.local</source-ad-name>
<!-- source-ad-partition = root AD domain partition -->
<source-ad-partition>dc=domain,dc=local</source-ad-partition>
<!-- source-ad-account = use this to specify an account to connect to AD -->
<!-- if not used, the current user will be used -->
<source-ad-account>ldapquery</source-ad-account>
<account-domain>domain</account-domain>
<!-- target-dn = target ADAM OU -->
<target-dn>dc=domain,dc=local</target-dn>
<query>
<!-- base-dn = should be the root AD partition if you want all users -->
<base-dn>dc=domain,dc=local</base-dn>
<!-- object-filter = standard ldap query format, this will grab all users -->
<!-- need to review results to see if you should modify this filter -->
<object-filter>(objectCategory=person)</object-filter>
<attributes>
<!-- include=userproxy requires objectSID to link back to the AD account -->
<include>objectSID</include>
<include>givenName</include>
<include>sn</include>
<include>description</include>
<include>title</include>
<include>company</include>
<include>department</include>
<include>mail</include>
<include>physicalDeliveryOfficeName</include>
<include>telephoneNumber</include>
<include>sAMAccountName</include>
</attributes>
</query>
<!-- map for user-to-userproxy object types -->
<user-proxy>
<source-object-class>user</source-object-class>
<target-object-class>userProxy</target-object-class>
</user-proxy>
<schedule>
<aging>
<frequency>0</frequency>
<num-objects>0</num-objects>
</aging>
<schtasks-cmd></schtasks-cmd>
</schedule>
</configuration>
<synchronizer-state>
<dirsync-cookie></dirsync-cookie>
<status></status>
<authoritative-adam-instance></authoritative-adam-instance>
<configuration-file-guid></configuration-file-guid>
<last-sync-attempt-time></last-sync-attempt-time>
<last-sync-success-time></last-sync-success-time>
<last-sync-error-time></last-sync-error-time>
<last-sync-error-string></last-sync-error-string>
<consecutive-sync-failures></consecutive-sync-failures>
<user-credentials></user-credentials>
<runs-since-last-object-update></runs-since-last-object-update>
<runs-since-last-full-sync></runs-since-last-full-sync>
</synchronizer-state>
</doc>
Notice the bits in bold. These are the attribute I want to Sync. I am also syncing these attributes FROM a user object TO a userProxy object. Let's use the "Active Directory Schema" mmc snap-in to look at the LDS Instance schema. To understand how to use "Active Directory Schema" mmc snap-in to connect to an LDS Instance please read:
http://technet.microsoft.com/en-us/library/cc816707.aspx
Your also going to probably run into this problem when connecting to the LDS Instance:
http://clintboessen.blogspot.com/2011/06/lds-active-directory-schema-status.html
In this environment I imported the following schema extensions MS-UserProxy.ldf, MS-AdamSyncMetadata.ldf, MS-AdamSchemaW2K8.ldf to my LDS Instance. In my Active Directory Schema if I look at my userProxy class object attribute association I have the following attributes associated:
However in my user class object I have the following attributes associated:
Can you pick the problem yet? I have asked ADAMSync to sync the following attributes FROM user class in Active Directory TO userProxy:
<attributes>
<!-- include=userproxy requires objectSID to link back to the AD account -->
<include>objectSID</include>
<include>givenName</include>
<include>sn</include>
<include>description</include>
<include>title</include>
<include>company</include>
<include>department</include>
<include>mail</include>
<include>physicalDeliveryOfficeName</include>
<include>telephoneNumber</include>
<include>sAMAccountName</include>
</attributes>
userProxy does not have these attributes associated. After I added these attributes to the userProxy class object all was fixed:
Processing Entry: Page 18, Frame 1, Entry 48, Count 1, USN 0
Processing source entry
Processing in-scope entry 08080633da0dfe4f8b46508f00f2708f.
Adding target object CN=JoeBlow,OU=Disabled accounts,OU=IS Users,OU=IS,DC=Domain,DC=Local.
Adding attributes: sourceobjectguid, sn, title, description, physicalDeliveryOfficeName, telephoneNumber, givenName, instanceType, department, company, objectSid, sAMAccountName, lastagedchange, objectclass,
Ldap error occured. ldap_add_sW: Object Class Violation.
Extended Info: 0000207D: UpdErr: DSID-0315121C, problem 6002 (OBJ_CLASS_VIOLATION), data 19
.
Ldap error occured. ldap_add_sW: Object Class Violation.
Extended Info: 0000207D: UpdErr: DSID-0315121C, problem 6002 (OBJ_CLASS_VIOLATION), data 19
.
************
************
************ A fatal error occured in the program while processing entry
************ GUID=08080633da0dfe4f8b46508f00f2708f
************ The error will be ignored at user request. Continuing...
************
************
Below I will explain how to resolve this. I am syncing all User Objects from Active Directory to userProxy objects in LDS. This is required for single sign on (SSO). userProxy objects forward authentication bind requests to domain controllers which process the authentication request, pass it back to LDS then to the client.
To understand this in more detail please read my following blog post on the userProxy class:
http://clintboessen.blogspot.com/2011/04/userproxy-class-and-adam-lds.html
Here is a copy of my XML configuration file I installed into ADAMSync:
<?xml version="1.0"?>
<doc>
<configuration>
<!-- Sync File Description -->
<description>ADAMSync Configuration</description>
<security-mode>object</security-mode>
<!-- source-ad-name = fqdn of the domain controller -->
<source-ad-name>domaincontroller.domain.local</source-ad-name>
<!-- source-ad-partition = root AD domain partition -->
<source-ad-partition>dc=domain,dc=local</source-ad-partition>
<!-- source-ad-account = use this to specify an account to connect to AD -->
<!-- if not used, the current user will be used -->
<source-ad-account>ldapquery</source-ad-account>
<account-domain>domain</account-domain>
<!-- target-dn = target ADAM OU -->
<target-dn>dc=domain,dc=local</target-dn>
<query>
<!-- base-dn = should be the root AD partition if you want all users -->
<base-dn>dc=domain,dc=local</base-dn>
<!-- object-filter = standard ldap query format, this will grab all users -->
<!-- need to review results to see if you should modify this filter -->
<object-filter>(objectCategory=person)</object-filter>
<attributes>
<!-- include=userproxy requires objectSID to link back to the AD account -->
<include>objectSID</include>
<include>givenName</include>
<include>sn</include>
<include>description</include>
<include>title</include>
<include>company</include>
<include>department</include>
<include>mail</include>
<include>physicalDeliveryOfficeName</include>
<include>telephoneNumber</include>
<include>sAMAccountName</include>
</attributes>
</query>
<!-- map for user-to-userproxy object types -->
<user-proxy>
<source-object-class>user</source-object-class>
<target-object-class>userProxy</target-object-class>
</user-proxy>
<schedule>
<aging>
<frequency>0</frequency>
<num-objects>0</num-objects>
</aging>
<schtasks-cmd></schtasks-cmd>
</schedule>
</configuration>
<synchronizer-state>
<dirsync-cookie></dirsync-cookie>
<status></status>
<authoritative-adam-instance></authoritative-adam-instance>
<configuration-file-guid></configuration-file-guid>
<last-sync-attempt-time></last-sync-attempt-time>
<last-sync-success-time></last-sync-success-time>
<last-sync-error-time></last-sync-error-time>
<last-sync-error-string></last-sync-error-string>
<consecutive-sync-failures></consecutive-sync-failures>
<user-credentials></user-credentials>
<runs-since-last-object-update></runs-since-last-object-update>
<runs-since-last-full-sync></runs-since-last-full-sync>
</synchronizer-state>
</doc>
Notice the bits in bold. These are the attribute I want to Sync. I am also syncing these attributes FROM a user object TO a userProxy object. Let's use the "Active Directory Schema" mmc snap-in to look at the LDS Instance schema. To understand how to use "Active Directory Schema" mmc snap-in to connect to an LDS Instance please read:
http://technet.microsoft.com/en-us/library/cc816707.aspx
Your also going to probably run into this problem when connecting to the LDS Instance:
http://clintboessen.blogspot.com/2011/06/lds-active-directory-schema-status.html
In this environment I imported the following schema extensions MS-UserProxy.ldf, MS-AdamSyncMetadata.ldf, MS-AdamSchemaW2K8.ldf to my LDS Instance. In my Active Directory Schema if I look at my userProxy class object attribute association I have the following attributes associated:
However in my user class object I have the following attributes associated:
Can you pick the problem yet? I have asked ADAMSync to sync the following attributes FROM user class in Active Directory TO userProxy:
<attributes>
<!-- include=userproxy requires objectSID to link back to the AD account -->
<include>objectSID</include>
<include>givenName</include>
<include>sn</include>
<include>description</include>
<include>title</include>
<include>company</include>
<include>department</include>
<include>mail</include>
<include>physicalDeliveryOfficeName</include>
<include>telephoneNumber</include>
<include>sAMAccountName</include>
</attributes>
userProxy does not have these attributes associated. After I added these attributes to the userProxy class object all was fixed:
LDS Active Directory Schema Status Unavailable
Back when LDS (Lightweight Directory Services) was called ADAM (Active Directory Application Mode) there was a console known as "ADAM Schema" which was the ADAM version of the "Active Directory Schema" MMC console.
Now with LDS the "ADAM Schema" no longer exists. Microsoft say to use "Active Directory Schema" for both LDS and Active Directory databases. For the TechNet article please see:
http://technet.microsoft.com/en-us/library/cc816707.aspx
I setup an LDS instance running on TCP10001. When I try and connect to the instance using Active Directory Schema on localhost:10001 it comes up as available. However I know my instance is there as I can connect to it using ADSIEdit.
I found out if you connect using the IP address of the server's primary network interface card it connects successfully.
Must be something dodgy embedded into the code of the Active Directory Schema snap-in.
Now with LDS the "ADAM Schema" no longer exists. Microsoft say to use "Active Directory Schema" for both LDS and Active Directory databases. For the TechNet article please see:
http://technet.microsoft.com/en-us/library/cc816707.aspx
I setup an LDS instance running on TCP10001. When I try and connect to the instance using Active Directory Schema on localhost:10001 it comes up as available. However I know my instance is there as I can connect to it using ADSIEdit.
I found out if you connect using the IP address of the server's primary network interface card it connects successfully.
Must be something dodgy embedded into the code of the Active Directory Schema snap-in.
Monday, June 6, 2011
Allowing Domain Membership through a Cisco Firewall
When setting up windows networks a DMZ must be created. This DMZ cannot contain any PC's that are a member of your internal Active Directory domain for security reasons. For your SME companies best practice is to generally configure all machines in your DMZ in a workgroup setup. For your enterprise companies best practice is to create a separate active directory forest for your DMZ. This allows centralised management over your DMZ servers allowing administrators to control servers using things such as Group Policy and WSUS.
However there are times where you need to allow PC's in your DMZ to access your internal Active Directory. For example I needed to setup an ADAM server to synchronise only particular attributes from various domains in an Active Directory forest which to be exposed to the internet using LDAPS (Secure LDAP) on secure port 636 for an external application. This ADAM server needs to be a member of of the Active Directory domain as I require User Proxy Bind Redirection to forward authentication requests through to an Active Directory domain controller. We created a separate DMZ just to contain this server requiring domain membership.
For more information on User Proxy Bind Redirection see:
http://clintboessen.blogspot.com/2011/04/userproxy-class-and-adam-lds.html
Windows machines are not very "firewall friendly". To start off with we opened up the following ports between our isolated "Domain DMZ" and our internal network:
UDP 53 – DNS Queries
TCP 88 – Kerberos v5 over TCP
UDP 88 – Kerberos v5 over UDP
TCP 135 – Microsoft Report Procedure Call Endpoint Mapper
UDP 389 – Unsecure LDAP over UDP
TCP 389 – Unsecure LDAP over TCP
TCP 443 – WSUS Windows Updates
TCP 445 – Simple Message Block Protocol
TCP 1688 – Key Management Server
TCP 3268 – Global Catalog Requests
TCP 3389 – Remote Desktop for management purposes
All the ports above still do not allow a workstation to be a member of an Active Directory domain due to the DCOM RPC ports. Microsoft RPC (MS-RPC) does not only use port TCP135 it also uses randomly generated ports from TCP 1024-65535 for XP/2003 and TCP 49152-65535 for Vista/2008 upwards. These are frequently informally referred to as "random RPC ports." In these cases, RPC clients rely on the RPC Endpoint Mapper (EPM) which runs on TCP135 to tell them which dynamic port(s) were assigned to the server.
Multiple components from the underlining windows subsystem get assigned their own dynamic RPC port every time the windows PC boots. These components include:
- Active Directory (Local Security Authority) – Runs on each domain member!
- Certificate Services
- Cluster Service
- Distributed File System
- Distributed File System Replication
- Distributed Link Tracking Server
- Distributed Transaction Coordinator
- Outlook MAPI Client
- ISA Server
- Fax Service
- File Replication
- FTP Publishing Service
- Group Policy
- Net Logon
- Remote Storage Notification
- Remote Storage Server
- Systems Management Server 2.0
- Terminal Services Licensing
- Terminal Services Session Directory
All these windows components get a dynamic port each time the system boots. RPC clients discover which port these services are on by querying TCP 135 (the port mapper).
So how did we get around this without opening every port from 1024-65535?
Our corporate firewall is currently a Cisco ASA 5540 running OS v8.4(1). The lastest Cisco OS software for the 5540 has integrated smarts for the Windows RPC Endpoint Mapper (EPM) running on TCP135. Cisco refers to this as "DCERPC".
This process works as follows:
1. A client queries an EPM server for the dynamically-allocated port number of a required DCERPC service. The EPM server listens on the well-known TCP port 135.
2. The ASA, located between the client and EPM server, intercepts the communication.
3. The EPM server indicates the port number on which the DCERPC service is available.
4. The ASA opens a pinhole for that DCERPC service.
This allows us to make the access control lists (ACLs) as tight as possible maintaining security whilst allowing application functionality through the ASA firewall.
Here is the Syntax used for configuring this functionality on our ASA:
class-map dcerpc
match port tcp eq 135
policy-map interface_dcerpc
class dcerpc
inspect dcerpc
service-policy interface_dcerpc interface dmz_adam
interface_dcerpc is our custom Service Policy
dmz_adam is our costom interface
Of course you also need to allow TCP135 (the RPC Port Mapper) in the ACL rules for this to work!
For more information on these dynamically generated RPC ports used by Windows Systems please see the following Microsoft knowledge base articles:
http://support.microsoft.com/kb/154596
http://support.microsoft.com/kb/832017
A big thank you to Peter Revill (CCIE #18371 Routing and switching, Voice) for helping me out on this one.
However there are times where you need to allow PC's in your DMZ to access your internal Active Directory. For example I needed to setup an ADAM server to synchronise only particular attributes from various domains in an Active Directory forest which to be exposed to the internet using LDAPS (Secure LDAP) on secure port 636 for an external application. This ADAM server needs to be a member of of the Active Directory domain as I require User Proxy Bind Redirection to forward authentication requests through to an Active Directory domain controller. We created a separate DMZ just to contain this server requiring domain membership.
For more information on User Proxy Bind Redirection see:
http://clintboessen.blogspot.com/2011/04/userproxy-class-and-adam-lds.html
Windows machines are not very "firewall friendly". To start off with we opened up the following ports between our isolated "Domain DMZ" and our internal network:
UDP 53 – DNS Queries
TCP 88 – Kerberos v5 over TCP
UDP 88 – Kerberos v5 over UDP
TCP 135 – Microsoft Report Procedure Call Endpoint Mapper
UDP 389 – Unsecure LDAP over UDP
TCP 389 – Unsecure LDAP over TCP
TCP 443 – WSUS Windows Updates
TCP 445 – Simple Message Block Protocol
TCP 1688 – Key Management Server
TCP 3268 – Global Catalog Requests
TCP 3389 – Remote Desktop for management purposes
All the ports above still do not allow a workstation to be a member of an Active Directory domain due to the DCOM RPC ports. Microsoft RPC (MS-RPC) does not only use port TCP135 it also uses randomly generated ports from TCP 1024-65535 for XP/2003 and TCP 49152-65535 for Vista/2008 upwards. These are frequently informally referred to as "random RPC ports." In these cases, RPC clients rely on the RPC Endpoint Mapper (EPM) which runs on TCP135 to tell them which dynamic port(s) were assigned to the server.
Multiple components from the underlining windows subsystem get assigned their own dynamic RPC port every time the windows PC boots. These components include:
- Active Directory (Local Security Authority) – Runs on each domain member!
- Certificate Services
- Cluster Service
- Distributed File System
- Distributed File System Replication
- Distributed Link Tracking Server
- Distributed Transaction Coordinator
- Outlook MAPI Client
- ISA Server
- Fax Service
- File Replication
- FTP Publishing Service
- Group Policy
- Net Logon
- Remote Storage Notification
- Remote Storage Server
- Systems Management Server 2.0
- Terminal Services Licensing
- Terminal Services Session Directory
All these windows components get a dynamic port each time the system boots. RPC clients discover which port these services are on by querying TCP 135 (the port mapper).
So how did we get around this without opening every port from 1024-65535?
Our corporate firewall is currently a Cisco ASA 5540 running OS v8.4(1). The lastest Cisco OS software for the 5540 has integrated smarts for the Windows RPC Endpoint Mapper (EPM) running on TCP135. Cisco refers to this as "DCERPC".
This process works as follows:
1. A client queries an EPM server for the dynamically-allocated port number of a required DCERPC service. The EPM server listens on the well-known TCP port 135.
2. The ASA, located between the client and EPM server, intercepts the communication.
3. The EPM server indicates the port number on which the DCERPC service is available.
4. The ASA opens a pinhole for that DCERPC service.
This allows us to make the access control lists (ACLs) as tight as possible maintaining security whilst allowing application functionality through the ASA firewall.
Here is the Syntax used for configuring this functionality on our ASA:
class-map dcerpc
match port tcp eq 135
policy-map interface_dcerpc
class dcerpc
inspect dcerpc
service-policy interface_dcerpc interface dmz_adam
interface_dcerpc is our custom Service Policy
dmz_adam is our costom interface
Of course you also need to allow TCP135 (the RPC Port Mapper) in the ACL rules for this to work!
For more information on these dynamically generated RPC ports used by Windows Systems please see the following Microsoft knowledge base articles:
http://support.microsoft.com/kb/154596
http://support.microsoft.com/kb/832017
A big thank you to Peter Revill (CCIE #18371 Routing and switching, Voice) for helping me out on this one.
Alternate Witness Server in Database Availability Groups
In this post we will look at the Alternate Witness Server - what is it?
The Alternate Witness Server provides a replacement witness server for a DAG to use after a datacenter switchover. When you are performing a datacenter switchover, you’re restoring service and data to an alternate or standby datacenter after you’ve deemed your primary datacenter un-usable from a messaging service perspective.
Although you can configure an Alternate Witness Server (and corresponding Alternate Witness Directory) for a DAG at any time, the Alternate Witness Server will not be used by the DAG until part-way through a datacenter switchover; specifically, when the Restore-DatabaseAvailabilityGroup cmdlet is used.
The Alternate Witness Server itself does not provide any redundancy for the Witness Server, and DAGs do not dynamically switch witness servers, nor do they automatically start using the Alternate Witness Server in the event of a problem with the Witness Server.
The reality is that the Witness Server does not need to be made redundant. In the event the server acting as the Witness Server is lost, it is a quick and easy operation to configure a replacement Witness Server from either the Exchange Management Console or the Exchange Management Shell.
The Alternate Witness Server provides a replacement witness server for a DAG to use after a datacenter switchover. When you are performing a datacenter switchover, you’re restoring service and data to an alternate or standby datacenter after you’ve deemed your primary datacenter un-usable from a messaging service perspective.
Although you can configure an Alternate Witness Server (and corresponding Alternate Witness Directory) for a DAG at any time, the Alternate Witness Server will not be used by the DAG until part-way through a datacenter switchover; specifically, when the Restore-DatabaseAvailabilityGroup cmdlet is used.
The Alternate Witness Server itself does not provide any redundancy for the Witness Server, and DAGs do not dynamically switch witness servers, nor do they automatically start using the Alternate Witness Server in the event of a problem with the Witness Server.
The reality is that the Witness Server does not need to be made redundant. In the event the server acting as the Witness Server is lost, it is a quick and easy operation to configure a replacement Witness Server from either the Exchange Management Console or the Exchange Management Shell.
Exchange 2010 Max Message Size Precedence
In Exchange 2007/2010 you can set SMTP message size quota's in 3 locations:
- Global Settings (Set-TransportConfig)
- Receive Connectors (Set-ReceiveConnector)
- Send Connectors (Set-SendConnector)
But which of these have Precedence?
The more restrictive limits always take precedence.
If you set the SMTP message size quota on a receive connector to 50MB but leave the TransportConfig quota to 10MB - Exchange will still only be able to receive 10MB emails.
If you set the SMTP message size quota on the TransportConfig to 50MB but leave a receive connector at 10MB - Exchange will only be able to receive 10MB emails on that particular receive connector.
To increase message size quota's you need to ensure you configure Every Receive connector, Send connector and the Global Settings on the transport config.
Why does it behave like this?
With Exchange 2003 and before, messages can pass directly between local
mailboxes as long as they don't need a (RG or SMTP) connector.
In that sense, the global limit is not applied to all messages.
Now, all messages need a Hub transport, including messages from a local
mailbox to another local mailbox. So, the global limit is always respected.
- Global Settings (Set-TransportConfig)
- Receive Connectors (Set-ReceiveConnector)
- Send Connectors (Set-SendConnector)
But which of these have Precedence?
The more restrictive limits always take precedence.
If you set the SMTP message size quota on a receive connector to 50MB but leave the TransportConfig quota to 10MB - Exchange will still only be able to receive 10MB emails.
If you set the SMTP message size quota on the TransportConfig to 50MB but leave a receive connector at 10MB - Exchange will only be able to receive 10MB emails on that particular receive connector.
To increase message size quota's you need to ensure you configure Every Receive connector, Send connector and the Global Settings on the transport config.
Why does it behave like this?
With Exchange 2003 and before, messages can pass directly between local
mailboxes as long as they don't need a (RG or SMTP) connector.
In that sense, the global limit is not applied to all messages.
Now, all messages need a Hub transport, including messages from a local
mailbox to another local mailbox. So, the global limit is always respected.
Thursday, June 2, 2011
The security database on the server does not have a computer account for this workstation trust relationship
After joining a new Windows Server 2008 R2 member server to the domain I was not able to log in, even with a Domain Admin account. The following error was experianced:
The security database on the server does not have a computer account for this workstation trust relationship
After some investigation it turns out the computer new computer account did not have a SPN (Service Principal Name). This is stored in the servicePrincipalName attribute in Active Directory. Below is a screenshot from ADSIEdit:
I added two SPN's to the computer account object in Active Directory in the format of:
HOST/COMPUTERNAME
HOST/COMPUTERNAME.domain.local
I was then able to log in to the new workstation.
The security database on the server does not have a computer account for this workstation trust relationship
After some investigation it turns out the computer new computer account did not have a SPN (Service Principal Name). This is stored in the servicePrincipalName attribute in Active Directory. Below is a screenshot from ADSIEdit:
I added two SPN's to the computer account object in Active Directory in the format of:
HOST/COMPUTERNAME
HOST/COMPUTERNAME.domain.local
I was then able to log in to the new workstation.
Subscribe to:
Posts (Atom)
