Skip to main content
Question

Unable to create Active Directory connection


I'm sure this is answered somewhere but I can't seem to find it. I'm having issues finishing up the AD Connector.

 

I've created a search account and verified it's credentials and began the basic setup for the connector. We have Basic authentication and the correct port is being used, but when we test the connection it says "Unable to authenticate with directory server with given credentials (49)". If I look at the logs it says it successfully establishes a connection with our DC but it fails to authenticate with out search account.

 

Is there something painfully obvious I'm missing (and that I can't find searching these forums)?

4 replies

Forum|alt.badge.img+2

Hi @zlegault​ ,

Usually this error is indicative that there has been a typo in the password, or the username has been incorrectly set up with the domain.

 

If you have triple checked these are both correct the next thing would be to confirm that this service account has read access to the domain controller?


  • Author
  • August 19, 2020
hollyatsafe wrote:

Hi @zlegault​ ,

Usually this error is indicative that there has been a typo in the password, or the username has been incorrectly set up with the domain.

 

If you have triple checked these are both correct the next thing would be to confirm that this service account has read access to the domain controller?

I've confirmed the username and password more times than I care to check but to be sure I just reset it, tested the creds, then updated the FME server console with no change. What kind of access does it need for "read access to domain controller"? This is a bit vague even in the KB linked below, as read access tends to be fairly granular. Does the account just need remote access? Does it need to have delegate access to the domain in ACUC?

 

https://docs.safe.com/fme/2020.0/html/FME_Server_Documentation/WebUI/Create-AD-Server-Connection.htm

 


richardatsafe
Safer
Forum|alt.badge.img+10

Hi @zlegault​ ,

 

Typically the search user just need to be a Domain Users, but in some cases the organisation will alter the default security and additional group roles such as Account Operators may be needed. Beyond that I would make sure you have supplied your search account as the Domain\\Username and that you are connecting directly to a single Domain Controller.


  • Author
  • August 20, 2020
richardatsafe wrote:

Hi @zlegault​ ,

 

Typically the search user just need to be a Domain Users, but in some cases the organisation will alter the default security and additional group roles such as Account Operators may be needed.  Beyond that I would make sure you have supplied your search account as the Domain\Username and that you are connecting directly to a single Domain Controller. 

So we have a search user, it's creds are correct, and it's already input as domain\account. All our authenticate goes to the same DC I've put in the host server.

When I check the logs, again, it can hit the host server just fine.

Thu-20-Aug-2020 01:41:42.111 AM   INFORM   pool-5-thread-1   408040 : (Active DirectoryConfigured to use simple authentication.
Thu-20-Aug-2020 01:41:42.111 AM   INFORM   pool-5-thread-1   408007 : (Active DirectoryAuthenticating user "domain.local\username"...
Thu-20-Aug-2020 01:41:42.113 AM   INFORM   pool-5-thread-1   408060 : (Active DirectorySuccessfully connected to HOSTSERVER.DOMAIN.local.
Thu-20-Aug-2020 01:41:42.117 AM   ERROR    pool-5-thread-1   408071 : Unable to authenticate with directory server with given credentials (49)
Thu-20-Aug-2020 01:41:42.117 AM   ERROR    pool-5-thread-1   408010 : (Active DirectoryException: "80090308: LdapErrDSID-0C090442commentAcceptSecurityContext errordata 52ev3839 "

The above logs have had our domain and username cut out for security purposes but otherwise this is all I can see for the error - I can't seem to find much on final error though.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings