Jump to content

Additional Domain Setup


tburke

Recommended Posts

Is there any extra documentation or advice you could give to help me debug a domain connection issue.  I've added a secondary domain to our main PasswordState server and it's setup nearly the same as our main domain which seems to work fine ( LDAPS - Port 636).  Just need some help trying to figure out from PasswordState's point of view to debug this.  This is what I've tried. 

 

We have opened up the 636 LDaps port in our firewall.  Looks like the port is listening and I can touch it.

Verified that from my PasswordState Server, I can run Test-NetConnection to the secondary domain:

 

PS C:\Users\Tburke> Test-NetConnection -ComputerName <fqdn here> -Port 636


ComputerName     : <fqdn here>
RemoteAddress    : 192.168.1.20
RemotePort       : 636
InterfaceAlias   : Ethernet0
SourceAddress    : 192.168.0.10
TcpTestSucceeded : True

 

Used the Windows ldp.exe to make a connection to the secondary domain.  (works)

 

image.png.098f60501a1d8a8a4e5dfa9d0529db7a.png

 

 

The next thing I tried was downloading the open source LDAP Admin app and connected again on port 636 with an AD user from the other domain.  I was able to see OU from this tool and make the connection.  So where do I go from here to trouble shoot this in PasswordState?  I didn't see much in the web log and nothing came up in the error console.  I'm trying to figure out what I might try next to debug this?

 

In Passwordstate when I try to add a user from this secondary domain, I get this displayed:

 

Quote
black-error-16.png Active Directory Query Error
 
It appears an error has occured trying to query Active Directory for user information.
 
Please check the 'Active Directory Domain Name' value specified below is correct. If not, please update in the 'Active Directory Domains' screen.
 
Active Directory Information
NetBIOS Name: <my secondary domain here>
FQDN: <fqdn domain, just like I have it in my main domain>
LDAP Query String: dc=blah,dc=org
 
Troubleshooting Step 1
Please ensure the account and password are correct for the Privileged Account you have associated with this domain, and that the account is not locked out - navigate to the screen Administration -> Passwordstate Administration -> Privileged Account Credentials.
 
Troubleshooting Step 2
If you are unsure what the settings are meant to be for Active Directory, please use this guide:
 
  • Open a command prompt on your computer and type set userdomain - the value returned from this should be the NetBIOS Name.
  • Whilst the command prompt is still open, type set userdnsdomain - the values returned here should make up the values in the LDAP Query String i.e. if the returned values are clickstudios.com.au, then your LDAP Query String should read dc=clickstudios,dc=com,dc=au
Troubleshooting Step 3
On the screen Administration -> Passwordstate Administration -> Active Directory Domains, ensure you have at least one Domain which is set to be the Default Domain.

 

Link to comment
Share on other sites

Hello,

 

If you go to the screen Administration -> Security Groups -> Debug AD Security Groups, does it report an error about invalid username or password when testing here? We've had another customer report this recently, which we're currently looking into to see if we can reproduce the issue. 

 

Can you also try resetting the password in AD for the Privileged Account Credential being used here, and then update it also on the screen Administration -> Privileged Account Credentials? Does this help at all?

Regards

Click Studios

Link to comment
Share on other sites

When doing a security group details search query I see this in the debug information box.  I'm using a user from that secondary domain here and I've tested to make sure that it's a valid user.

 

Quote

Debug 0: Error executing function 'QueryADGroup()'. Error Message = The user name or password is incorrect. , Stack trace = at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne) at admin_securitygroups_testad.QueryADGroup()

 

Link to comment
Share on other sites

Hi tburke,

 

I've been doing quite a bit of testing this morning, but cannot seem to reproduce this issue - I am testing with two domains, where the password for each Privileged Account Credential is different. It's using the correct password each time, and querying AD without any issues for me.

 

Can you try my suggestion of "Can you also try resetting the password in AD for the Privileged Account Credential being used here, and then update it also on the screen Administration -> Privileged Account Credentials?"

 

Can you let me know if that makes any different when you do this? And also ensure the password is different from the other domain, so we are sure we're using the correct one here.

Thanks

Click Studios

Link to comment
Share on other sites

Hi tburke,

 

I think we may have found one issue with testing here now. With the "LDAP Filter" textbox, can you clear this and let us know if you can then query the domain on this Debug screen?

We have one domain where we get this error, but the other domain works fine when it is populated - so we need to investigate why this is.

Regards

Click Studios

Link to comment
Share on other sites

Hi tburke,

 

We believe we've fixed out what the issue could be. If you are querying a non-trusted domain, you may need to prefix a domain controller with the LDAP Filter textbox i.e. in the following format: adserver.domain.com/cn=users,dc=domain,dc=com

 

So what we've done in the next build is ensure this LDAP Filter textbox remains blank when swapping between domains, and then provide onscreen documentation to inform users of this requirement.

Can you let us know if this is the case for you also?

Regards

Click Studios

Link to comment
Share on other sites

Sorry, I thought I replied to this earlier today.  So that did work for me.  I was able to query some security groups from PasswordState into our secondary domain with that filter applied.  Thank you!  I'll let you know if we hit on any other issues. I'll be setting up the remote site in that domain.  Got some other stuff I got to get done so might be a few days before I can get it fully deployed out and tested.

 

So it kind of sounds like our common denominator here was the "untrusted" part in that second domain maybe.

Link to comment
Share on other sites

Quote

If you blank out this Filter value, it seems to work for us also.

 

I just read that post again.  So to be clear, it wasn't blanking out of the filter that worked for me, it was adding the:

 

Quote

prefix a domain controller with the LDAP Filter textbox i.e. in the following format: adserver.domain.com/cn=users,dc=domain,dc=com

 

When I added this to the domain setup, I was able to query security groups without getting an error message saying user wasn't valid.

 

adserver.domain.com/cn=users

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...