LDAP AD Authentication Issues



“invalid user” error when attempting to login to Foreman after setting up LDAP auth connecting to Active Directory.

Expected outcome:

User should be able to login but logs indicate invalid user. It seems as if the account used to BIND to the AD is not being established.

Foreman and Proxy versions:


Foreman and Proxy plugin versions:

Other relevant data:

2019-01-08T19:54:09 [I|app|] Started POST "/users/login" for at 2019-01-08 19:54:09 +0000
2019-01-08T19:54:09 [I|app|ce441] Processing by UsersController#login as HTML
2019-01-08T19:54:09 [I|app|ce441]   Parameters: {"utf8"=>"✓", "authenticity_token"=>"rrCz4KnC2egnphRr04+GYMweY0j6O+MB44v+aZUb1EvR2Z/gZ+KStLoB61XznRlOcHliKicAhD6maNVOfm90IQ==", "login"=>{"login"=>"drew.bentley@domain.com", "password"=>"[FILTERED]"}, "commit"=>"Log In"}
2019-01-08T19:54:09 [D|app|ce441] Attempting to log into an auth source as drew.bentley@domain.com for account auto-creation
2019-01-08T19:54:09 [I|app|ce441] invalid user
2019-01-08T19:54:09 [W|app|ce441] Failed login attempt from with username 'drew.bentley@domain.com'
2019-01-08T19:54:09 [I|app|ce441] Redirected to
2019-01-08T19:54:09 [I|app|ce441] Completed 302 Found in 17ms (ActiveRecord: 4.9ms)
2019-01-08T19:54:10 [I|app|] Started GET "/users/login" for at 2019-01-08 19:54:10 +0000
2019-01-08T19:54:10 [I|app|20b61] Processing by UsersController#login as HTML
2019-01-08T19:54:10 [I|app|20b61]   Rendering users/login.html.erb within layouts/login
2019-01-08T19:54:10 [I|app|20b61]   Rendered users/_welcome_box.html.erb (1.6ms)
2019-01-08T19:54:10 [I|app|20b61]   Rendered users/login.html.erb within layouts/login (2.5ms)
2019-01-08T19:54:10 [I|app|20b61]   Rendering layouts/base.html.erb
2019-01-08T19:54:10 [I|app|20b61]   Rendered layouts/base.html.erb (0.8ms)
2019-01-08T19:54:10 [I|app|20b61] Completed 200 OK in 5ms (Views: 3.9ms | ActiveRecord: 0.2ms)

AD Test Connection works successfully using our defaults AD.GLOBAL on port 389.

I think the issue now is our AD required authentication to query the Active Directory LDAP. From my Windows Administrators, the only way to pass the username that works is the principleName format (username@domain.com).

I’ve verified from the command line on the same foreman host that I can do successful queries with ldapsearch command:

ldapsearch -x -D drew.bentley@domain.com -W -H ldap://ad.global -b "CN=L-HID-CHGVA-Foreman,OU=CHGVA,OU=Security,OU=SecurityGroups,OU=HID,OU=SSC,DC=ad,DC=global"

I’ve tried using AD.GLOBAL\username in the Account under LDAP Account and the drew.bentley@domain.com without success. Anything I try it appears as if the BINDING is never established.

The Foreman docs claim to use the DOMAIN\username for the account login for queries but if that’s the only method or string to pass, how can I get around this to auth with my full email or principle name to BIND to the AD server with.

Thanks for any suggestions, tips, etc.


When I had problems with LDAP authentication increasing the debugging always helped me.

In /etc/foreman/settings.yaml you have to configure:

  :level: debug

But LDAP is a separate logger which needs to be enabled:

    :enabled: true

After debugging disable the logger again for security reasons as it can give you some sensitive data.


Yes, I’ve enabled that. The log snippet I provided is with debugging enabled and LDAP logging debug.


Hello. I’m having similar issues as well where I cannot login using my AD credentials.

I have the LDAP server and account setup and when I click on “Test Connection”, it says successful, even though I’m not sure what its actually testing. That it can access the LDAP server or that it can authenticate to my AD using the account I provided.

I created external user groups to bind with security groups in my AD and I am able to refresh but I’m not sure if the “binding” is happening. How do I check this?

Also, what format should I be using for the username when I attempt to login, domain\username or username@domain.com?


The documentation uses example of DOMAIN\username but I’ve tried that format and user@domain.com without any such luck.

That’s why I raised this issue as when I’m doing an ldapsearch query, I have to use user@domain.com format so I’m not sure if that’s getting passed correctly for the binding within Foreman.


I’m assuming you have the “Automatically create accounts in foreman” checked which requires you to enter the attributes. I remember reading elsewhere that if you use “sAMAccountname” instead of “userPrincipalName” as the login name attribute, that allows you to login using the format domain\username. However, that didn’t work for me either, probably because that binding is not working.

Can someone in the community help us?


Please find my settings attached. Hopefully they help


Test connection only verifies Foreman can talk to AD, it does not try to authenticate currently logged in user. You can read recommendations in Foreman manual [1], scroll down to Active Directory.

[1] https://www.theforeman.org/manuals/1.20/index.html#5.7ExternalAuthentication

Reading the original issue, it seems you’re trying to bind using the account that’s logging in. IIRC Foreman needs to set the account for auth source, that is used to bind, then it searches for users in AD using this account. If drew.bentley is able to bind and has permissions to read users from AD, I suppose you set that account for AD auth source in Foreman, right?


I got this working. I can login now using my domain credentials. I had to use “sAMAccountName” as the Login Attribute instead of “userPrincipleName”. Just sharing to help others who may be stuck like I was. Thanks.




I’m trying to bind using the Account and Password that Foreman claims is “Optional” under the Account tab.

The only user configured for actual login to Foreman is the default local Admin user, so that account I would not attempt to use as a binding auth user.


can you send a screen shot of what your account tab looks like?
We simply created an account (service account) in our AD and then entered it into the account tab username/password fields with the domain prefix. Once you have this in place you can then link to the security groups in your AD.