We are trying to implement multiple domains. We have entries in the server.config file as indicated for each domain:
<DataSource Path="LDAP://DC=domain1,DC=com" NetBiosName="Domain1" Type="ActiveDirectory" />
<DataSource Path="LDAP://DC=domain2,DC=com" NetBiosName="Domain2" Type="ActiveDirectory" />
I have implemented the domain info as shown above, however I cannot browse users or authenticate to the second domain. Users from the first domain (which is where the server also resides, and the K2 service account resides) authenticate fine.
In our environment, NetBios is disabled, which our IT support surmises is the reason we cannot browse for users.
We can authenticate to users in the second domain through normal windows operations on the server, but K2 does not recognize them. If we try to log in as a user from the 2nd domain, the ADUMError.txt file in the /bin logs as:
16-08-05 02:12:27 GetUser
A referral was returned from the server
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.RefreshCache()
at ADUM.K2UserManager.GetDirectoryEntry(String path)
at ADUM.K2UserManager.GetUser(String Name)
Additional Information
GetUser(DOMAIN2MyUsersName)
Is NetBios the only supported protocol? Is something missing?
+6
Note: K2 SP2a is the first version to truly support Multiple Domains. This case was an upgrade of SP2 to SP2a running on Windows 2003 Server SP1.
+6
In between (the previous support ticket) and now, I managed to have some success. I changed the service account for the K2 service to be an account from Domain2, which is our DMZ domain (Domain1 is our back end trust domain where the workflow server resides). The service re-started fine, and now I can log in as Domain1 and Domain2 users (so far so good). It seems the code has a dependency likely on the server account for AD lookups?
[Note, I also tried included the domain controller in the LDAP string as I found on the forums, this didn t seem to make a difference however]
I have yet to create/export any processes in this environment and see if they assign properly within Domain2, but this is looking somewhat promising.
It should be noted though, that in this configuration, the user seems to get into the workspace OK, but the following is logged in the ADUMError.txt (and is repeated several times). It is a bit worrisome to see this error:
16-08-05 03:11:18 NameToDN
The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
at ActiveDs.NameTranslateClass.Init(Int32 lnSetType, String bstrADsPath)
at ADUM.Translate.NameToDN(String name)
Additional Information
NameToDN(Name: DOMAIN2Domain2UserName)
16-08-05 03:11:18 GetUser
Unknown error (0x80005000)
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.RefreshCache()
at ADUM.K2UserManager.GetDirectoryEntry(String path)
at ADUM.K2UserManager.GetUser(String Name)
Additional Information
GetUser(DOMAIN2Domain2UserName)
Thanks
[Note, I also tried included the domain controller in the LDAP string as I found on the forums, this didn t seem to make a difference however]
I have yet to create/export any processes in this environment and see if they assign properly within Domain2, but this is looking somewhat promising.
It should be noted though, that in this configuration, the user seems to get into the workspace OK, but the following is logged in the ADUMError.txt (and is repeated several times). It is a bit worrisome to see this error:
16-08-05 03:11:18 NameToDN
The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
at ActiveDs.NameTranslateClass.Init(Int32 lnSetType, String bstrADsPath)
at ADUM.Translate.NameToDN(String name)
Additional Information
NameToDN(Name: DOMAIN2Domain2UserName)
16-08-05 03:11:18 GetUser
Unknown error (0x80005000)
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.RefreshCache()
at ADUM.K2UserManager.GetDirectoryEntry(String path)
at ADUM.K2UserManager.GetUser(String Name)
Additional Information
GetUser(DOMAIN2Domain2UserName)
Thanks
+6
We have a dedicated infrastructure team here which handles our domain issues. They suspect that K2 is relying on NetBios to list users across domains. We have turned NetBIOS off for security reasons, and it is impractical to turn it back on.
Otherwise there is a transitive trust I believe between the domains.
...Every login is causing those errors to be logged, which I am guessing is not normal behaviour.
Otherwise there is a transitive trust I believe between the domains.
...Every login is causing those errors to be logged, which I am guessing is not normal behaviour.
+6
Working with resident AD expert and network expert, it turns out that LDAP and Kerberos traffic was being blocked from a firewall policy from their back domain to the front. Once this was enabled, client was able to have K2 run in a standard fashion, using a back end domain account as the service account, and being able to browse and authenticate front end accounts in the service manager and the workspace.
Client thinks this issue is tentatively resolved right now(...)
Additional resolution information:
Client has very strict firewall policies in place. LDAP and Kerberos traffic was explicitly not set as allowable from the Internal to the DMZ (where our Front end domain controller resides). Production would have the same issues, but now that this is known, the IT team will be making appropriate changes.
The indication of the firewall policy was found by the AD Admin because of the mis-match when going from Front end service account backwards (i.e. all accounts worked when the front end domain account was used) but the reverse was not true. As it turns out this was due to the traffic being blocked as mentioned (above).
Client thinks this issue is tentatively resolved right now(...)
Additional resolution information:
Client has very strict firewall policies in place. LDAP and Kerberos traffic was explicitly not set as allowable from the Internal to the DMZ (where our Front end domain controller resides). Production would have the same issues, but now that this is known, the IT team will be making appropriate changes.
The indication of the firewall policy was found by the AD Admin because of the mis-match when going from Front end service account backwards (i.e. all accounts worked when the front end domain account was used) but the reverse was not true. As it turns out this was due to the traffic being blocked as mentioned (above).
+9
Reply
View our Community Site Map
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.