The customer is unable to import Roles and Accounts with one of his AD Import Rules. He has multiple domains (for example: Office, Storage and Data center).
The one for Data center was getting the following errors while trying to import:
System.DirectoryServices.DirectoryServicesCOMException caught in ImportDirectoryDataThreadProc. Reason: The user name or password is incorrect.
OR
Unable to retrieve defaultNamingContext for: DataCenter.Local
The user name or password is incorrect.
However, the account used is trusted in the other domain.
Note: removed some of the trace entries for simplification.
Entry 1:
Unable to retrieve defaultNamingContext for: OrkinCanadaRoot.Local
The user name or password is incorrect.
....
COM Exception error code: 0x8007052E
.....
User [<Domain>\<UserName>], Auth [<Domain>\<UserName>], AppDomain [AeXSVC.exe]
-----------------------------------------------------------------------------------------------------
Date: 11/29/2018 4:25:14 PM, Tick Count: 1188462625 (13.18:07:42.6250000), Size: 4.37 KB
Process: AeXSvc (1352), Thread ID: 220, Module: Altiris.DirectoryServices.dll
Priority: 1, Source: Altiris.DirectoryServices.DirectoryExport.LDAPUtility.GetDefaultNamingContextEntry
Entry 2:
System.DirectoryServices.DirectoryServicesCOMException caught in ImportDirectoryDataThreadProc. Reason: The user name or password is incorrect.
The user name or password is incorrect.
.....
COM Exception error code: 0x8007052E
....
User [<Domain>\<UserName>], Auth [<Domain>\<UserName>], AppDomain [AeXSVC.exe]
-----------------------------------------------------------------------------------------------------
Date: 11/29/2018 4:25:14 PM, Tick Count: 1188462625 (13.18:07:42.6250000), Size: 3.93 KB
Process: AeXSvc (1352), Thread ID: 220, Module: Altiris.DirectoryServices.dll
Priority: 1, Source: Altiris.DirectoryServices.DirectoryImport.DirectoryImporter.HandleException
Entry 3:
Task error: The user name or password is incorrect.
The user name or password is incorrect.
[System.DirectoryServices.DirectoryServicesCOMException @ System.DirectoryServices]
at Altiris.DirectoryServices.NSDirectoryItems.DirectoryImportTask.DoDirectoryImportTask(String taskid, String importXml, Boolean bUpdateImport)
COM Exception errcode: 0x8007052E
....
User [<Domain>\<UserName>], Auth [<Domain>\<UserName>], AppDomain [AeXSVC.exe]
-----------------------------------------------------------------------------------------------------
Date: 11/29/2018 4:25:14 PM, Tick Count: 1188462625 (13.18:07:42.6250000), Size: 2.02 KB
Process: AeXSvc (1352), Thread ID: 113, Module: Altiris.DirectoryServices.dll
Priority: 1, Source: Altiris.DirectoryServices.NSDirectoryItems.DirectoryImportTask.SetException
Entry 4:
Unable to retrieve defaultNamingContext for: DataCenter.Local
The user name or password is incorrect.
[System.DirectoryServices.DirectoryServicesCOMException @ System.DirectoryServices]
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_AdsObject()
at System.DirectoryServices.PropertyValueCollection.PopulateList()
at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
at Altiris.DirectoryServices.DirectoryExport.LDAPUtility.FirstProperty(DirectoryEntry e, String name)
at Altiris.DirectoryServices.DirectoryExport.LDAPUtility.FirstPropertyString(DirectoryEntry e, String name, String def)
at Altiris.DirectoryServices.DirectoryExport.LDAPUtility.GetDefaultNamingContextEntry(String strServer, String strUserId, String strPassword)
COM Exception errcode: 0x8007052E
....
User [<Domain>\<UserName>], Auth [<Domain>\<UserName>], AppDomain [AeXSVC.exe]
-----------------------------------------------------------------------------------------------------
Date: 11/29/2018 4:27:39 PM, Tick Count: 1188607187 (13.18:10:07.1870000), Size: 3.10 KB
Process: AeXSvc (1352), Thread ID: 189, Module: Altiris.DirectoryServices.dll
Priority: 1, Source: Altiris.DirectoryServices.DirectoryExport.LDAPUtility.GetDefaultNamingContextEntry
ITMS 8.1 RU7
In the past we have noticed that in some environments with multiple domains, if the option "Use Global Catalog for cross searches" is selected in the AD Import Rule, it was causing issues. Most were because the account used didn't have full rights to every attribute that has been imported, or the Global Catalog used in the other domain was not configured the same way.
Here is a more technical explanation as to why the Global Catalog may or may not be needed in certain scenarios:
First: AD uses two different data storage structures installed to the Domain Controller (DC) when storing AD data. The traditional active directory database (AD) has information about it's own domain, but can't have any references to other domains. The Global Catalog (GC) is an independent database that can be installed on one or more DC's which mirrors many aspects of the AD data, but not all. Adding a GC to each domain adds the ability to reference objects across domains within a forest. This means that the GC enables a Global Security Group within a domain to contain members of the other domains. Each domain maintains all the objects that belong under that domain, but the relationships to that object are synchronized in the GC which can contain links back to the domain that each object resides in. Queries of the AD will only yield members that are part of it's own domain, while queries against the GC will yield results across the forest. To get details of an object, the domain would need to be queried directly. The AD listens on the LDAP port while GC has its own port. AD import uses the LDAP(389) port and also when available, the GC(3268) port, to get domain data. If the import specifies a specific DC then that DC will be used otherwise a DC will be chosen automatically by DNS. Either way, this DC will be used for queries for the local domain. The DC is identified if it has a GC available and if it is a root DC for the forest. When a GC is available it is often used instead of LDAP. When the cross option is enabled, many GC queries are sent to the forest root GC instead of the chosen DC, even if the DC was directly specified. When the cross option is disabled some of the GC queries are forced to LDAP to ensure only data for that domain is returned. When troubleshooting make sure to enable trace level logging and Ultra AD import verbose level, which will record the AD queries. Each AD query will have a description that starts with "AD Search:" which specifies a "root:", "filter:", and "properties:" strings. The root prefix will indicate if the LDAP or GC port was used. Using another LDAP tool like ldapbrowser the default port will be for LDAP; however, if the search in question was to a GC, then the tool will need to be switched to use the GC port. In this case it is very likely that the customer GC is not fully synchronized with the AD data, which is why, when the cross option was disabled, the broken searches were forced to use the LDAP port which did have the correct data.
The following was suggested and resolved the issue:
It may take a little bit longer than usual to finish (expected when it is the first time since it has to create all the resources) but after that you should be able to see those accounts for the desired domain.