80090308 ldaperr dsid 0c090447 comment acceptsecuritycontext error data 52e v3839

I ran into an issue when trying to connect to ldap server in my spring boot application.
I verified the URL, user name, and password are all valid using ADExplorer.
I also step trace the same information to make sure information is correct right before the call.

Hashtable<String, Object> env = new Hashtable<String, Object>();
env.put(Context.SECURITY_AUTHENTICATION, "simple");
if(ldapUsername != null) {
    env.put(Context.SECURITY_PRINCIPAL, ldapUsername);
}
if(ldapPassword != null) {
    env.put(Context.SECURITY_CREDENTIALS, ldapPassword);
}
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, ldapAdServer);
env.put("java.naming.ldap.attributes.binary", "objectSID");

ctx = new InitialLdapContext(env, null);<==== exception thrown
return ctx;

ldap:
    host:
      ldapadserver: ldap://ldapserver.com
    search:
      ldapsearchbase: OU=AD Master OU,OU=###,DC=###,DC=###
    user:
      ldapusername: ####
      ldappassword: ENC(#####)

Exception while loading user configuration file : javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839]
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839]
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3261)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3207)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2993)
        at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2907)
        at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:347)
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxFromUrl(LdapCtxFactory.java:225)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:189)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:243)
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
        at javax.naming.InitialContext.init(InitialContext.java:244)
        at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)

Just an update: I followed the advise and use the full DN string as ldapUserName and everything works.

Hello,

For the life of me I can get LDAP to work. We have an old version of teampass (2.1.23) and rather than going through the upgrade path, I figured maybe installing the latest version would be better and then just manually transfer the passwords over.

Installation of 3.0.0.7 went fine but I can’t get LDAP to function. I updated 3.0.0.7 to 3.0.0.8, and while I no longer get the «couldn’t connect to LDAP» error, I’m either getting an authentication error or just «in progress» with errors in the apache log.

I’ve tried all sorts of combinations. I can’t upload pictures from work, but if I use as the bind user the full distinguished name like for example:

Username : CN=sa_ldap,OU=ServiceAccounts,OU=foo,DC=bar,DC=com

User name attribute : cn

Then in the logs I get:

Uncaught LdapRecord\Query\ObjectNotFoundException: No LDAP query results for filter: [(**cn=CN=**sa_ldap,OU=ServiceAccounts,OU=foo,DC=bar,DC=com)] in: [] in /opt/websites/teampass-3.0.0.7/includes/libraries/LdapRecord/Query/ObjectNotFoundException.php

It adds this double CN=. Tried without, no luck. I must be doing something wrong. Is anyone getting LDAP to work with AD?

sAMAccountName does not work as others pointed out.

80090308 ldaperr dsid 0c090447 comment acceptsecuritycontext error data 52e v3839

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

We are developing a LDAP authentication against Active Directory, we met the follow errors, although the username and password are correct.

LDAP: error code 49 — 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece

The user detail is: CN=Peter, Lia ,OU=DEV,OU=HK_U,OU=cita,OU=US,DC=achtest,DC=local

As you may saw, the last name of this user has a backslash, plus a space in CN, we guess it may be the problem, since other users don’t have this problem if the last name of users don’t have a backslash and a space.

However we don’t know how we can add a new user to duplicate this issue, since it’s not way to add a new user with space in the end of name, the Active Directory will auto trim the space when system save the new user to database.

My questions are:

1. Do you have this kind of experience? Any idea to resolve?

2. How we can add a new user with a space in the end of last name? and then we can replicate this issue again?

Источник

LDAP Authentication fails if using sAMAccountName #2936

Comments

hitenmandalia commented Jun 29, 2021

Steps to reproduce

1. Configure username for connecting to AD with sAMAccountname
2. User name attribute set to sAMAccountName
3. User Object Filter set to (objectCategory=Person)(sAMAccountName=*))
4. Test configuration with sAMAccountName of a user

Expected behaviour

Actual behaviour

Caution
Error : 49 — Invalid credentials
80090308: LdapErr: DSID-0C090453, comment: AcceptSecurityContext error, data 52e, v3839

Server configuration

Operating system:
Alpine Linux

Web server:
Apache

Database:
Amazon Aurora RDS (mysql 5.7)

PHP version:
7.4

Teampass version:
3.0.0.8

Teampass configuration file:

Updated from an older Teampass or fresh install:
PLEASE attach to this issue the file /includes/config/tp.config.php .

Client configuration

Browser:

Operating system:

Web server error log

Log from the web-browser developer console (CTRL + SHIFT + i)

The text was updated successfully, but these errors were encountered:

nilsteampassnet commented Jul 3, 2021

Hello,
I have similar setup and it works smoothly.

While googling your error, I found this page https://ldapwiki.com/wiki/Common%20Active%20Directory%20Bind%20Errors
Perhaps this could help you but I don’t see how the Adldap could be wrong there.
I would be greatly interested in having any feedback.
Perhaps something needs to be robustified.

hitenmandalia commented Jul 6, 2021

This is the error I keep getting. I even get the same error when testing and using my own credentials which I know work.

hitenmandalia commented Jul 13, 2021 •

weird thing. If I use cn as the username with which to bind, change the username attribute to cn and then test the configuration with the following:

«firstname» «surname» (theres a space between the two), it succesfully passes. as soon as I change back to samaccountname it fails. @nilsteampassnet the only difference i can see between both of our configs is that you are using OpenLDAP whereas I am using Active Directory.

I did read somewhere about issues when the cn and samaccountname’s are different, but I cannot seem to find that link again and dont even know if this is a valid reason?

hitenmandalia commented Jul 21, 2021

hi @nilsteampassnet. Do you have any further updates on this?

Has anyone got TeamPass 3.0.0.8 working using samAccountName with Active Directory?

zorgman commented Jul 27, 2021 •

For the life of me I can get LDAP to work. We have an old version of teampass (2.1.23) and rather than going through the upgrade path, I figured maybe installing the latest version would be better and then just manually transfer the passwords over.

Installation of 3.0.0.7 went fine but I can’t get LDAP to function. I updated 3.0.0.7 to 3.0.0.8, and while I no longer get the «couldn’t connect to LDAP» error, I’m either getting an authentication error or just «in progress» with errors in the apache log.

I’ve tried all sorts of combinations. I can’t upload pictures from work, but if I use as the bind user the full distinguished name like for example:

User name attribute : cn

Then in the logs I get:

Uncaught LdapRecord\Query\ObjectNotFoundException: No LDAP query results for filter: [(**cn=CN=**sa_ldap,OU=ServiceAccounts,OU=foo,DC=bar,DC=com)] in: [] in /opt/websites/teampass-3.0.0.7/includes/libraries/LdapRecord/Query/ObjectNotFoundException.php

It adds this double CN=. Tried without, no luck. I must be doing something wrong. Is anyone getting LDAP to work with AD?

sAMAccountName does not work as others pointed out.

Источник

[TUTORIAL] How to join a Proxmox cluster to an Active Directory Domain

hackinthebox

New Member

This tutorial will walk through the steps necessary to join your Proxmox server to Microsoft Active Directory on a Windows 2019 Server.
You will be able to sync your users and groups into the Proxmox Permissions Panel in the GUI, and log into the web console with active directory credentials.

Here are the general steps:

1. Set basic settings
2. Add Active Directory Realm & Sync Users
3. Configure Permissions
4. Install packages from the repository
5. Join the Active Directory domain
6. Test your config

In this tutorial, our realm/domain will be infraredhat.com
Two domain controllers have been configured, and are acting as DNS servers.
Our subnet is 192.168.11.0/24

The Proxmox node a single network interface with a static IP of 192.168.11.10/24
The Domain Controllers (and DNS servers) have IP’s of 192.168.11.11 and 192.168.11.12.

Set the search domain to infraredhat.com, and set the DNS servers to the IP addresses of the Domain Controllers, 192.168.11.11 and 192.168.11.12.

Configure hosts file with your Proxmox server’s FQDN (and hostname) following the example below.

Navigate to the «Time» panel below «Hosts» currently selected in the menu and verify the correct time and Time Zone.

Add Active Directory Server

Next, Select «Datacenter» or the name of your cluster, and Navigate to Permissions > Realms > Add Realm > Active Directory Server.
Populate your domain and domain controller IP’s like the example below.

Click on the «Sync Options» Tab.
You’ll need Active Directory credentials to access domain controller users and groups. You can simply use the Administrator Account, but for more security, you can create a user account with read-only access to the domains objects instead. For demonstration, let’s use the built in «Administrator».

For the «Bind User», you’ll need to enter it a very specific way.
Navigate to your domain controller and open a powershell window as admin.

SUPER IMPORTANT. (AND NOT VERY WELL DOCUMENTED. )

For the correct string to enter for the Adminstrator in the infraredhat.com domain, you would enter the following command:

Enter the password for this user. For now you can ignore the remainder of the fields. I’ve set my default sync preferences in the screenshot.

Click OK to close and save.
You can now select your Active Directly Realm from the list (listed alongside PAM and PVE). Click SYNC from the menu and you should see your AD Users and Groups populate.

Configure permissions to tell Proxmox what access to give each user/group

Next, Navigate to the «Permissions» Menu > Add > Group Permission
I’ve selected the Administrators Group from Active directory, and assigned the PVE Administrator Role to this Group.
This way, any user in the AD Administrator group will also be a PVE Administrator.
Select ‘/’ to give full access as well.
Click OK.

Install additional packages needed for system security

Next, Navigate to a shell window on your PVE Node. There are a few packages to install and configure.
Update your packages, and install adcli, packagekit, samba-common-bin realmd
The remainder of the required packages will be auto-installed and configured.

Join the node to the domain

Next, test connection with the domain controller, and then join the domain. For additional options, see the man pages by running the command man realm . Since we’re doing a high level walkthrough, I’m keeping it simple. Because no user is specified in the join command, realmd defaults to «Administrator» for this action.

You’ll see an output with information about your DC and domain, along with additional required packages. Installing these in advance will cause the configurations to fail. Simply enter this command, substituting your own domain.

Follow the prompts, enter the Active Directory Admin password when prompted and allow the sssd and additional packages install.
You are now joined to the domain and you should see your Proxmox node appear as a computer in Active Directory Users and Computers. Congrats!

Configure additional settings and test your config

You can edit the config in /etc/sssd/sssd.conf. Run

— you should see UID and GID from your domain controller.

Finally, log out of Proxmox in the menu in the upper right hand corner, and test by logging in as Administrator@infraredhat.com in the login menu by selecting the Active Directory domain from the login drop-down instead of PAM. You should successfully authenticate and log in. Beware, you will not have shell access to Proxmox in the console. that’s only available to root, logged in under local PAM. For shell access, you’ll need to configure ssh separately.

Remember to add permissions to users and groups who need access in the PVE menu.
Repeat the package-install and domain-join process for each additional node that exists in a cluster. User and group sync and permissions are managed cluster-wide and only has to be configured once.

Источник

Users are unable to log in to JIRA (LDAP: error code 49, data 52e)

Atlassian Knowledge Base

On this page

Related content

Still need help?

The Atlassian Community is here for you.

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms .

Problem

Users are unable to log in. Nothing has changed in JIRA side.

The following appears in the atlassian-jira .log:

Cause

LDAP Error 49 data 52e means that the credentials of the user configured to bind LDAP directory with JIRA are incorrect, as described here: https://confluence.atlassian.com/kb/common-user-management-errors-820119309.html#CommonUserManagementErrors-ActiveDirectoryError49

This can happen when that user is either removed or has its password changed from LDAP side.

Resolution 1

Follow the steps outlined at Restore Passwords To Recover Admin User Rights. By doing so, you’ll be able to access the User Directory settings and change the «Username» field with a valid admin user or change the «Password» field with the new password, allowing JIRA to connect to LDAP.

Resolution 2

Alternatively, you can run the following query against your database to find out which one is the admin account that JIRA uses to connect to the LDAP:

Note: The query may return multiple results in case you have more than one User Directory in your JIRA instance.

Re-adding the user back to the LDAP with the same password should resolve the issue.

Resolution 3

As JIRA storing LDAP Login credential in the database without encryption, you may also update those LDAP credential in your database:

lDAP Password Field

LDAP User Name Field

attribute_value is the fields which storing those data.

Always perform a backup before you perform edit/update query in the database. It is also highly recommended for you to perform this in a test instance before proceeding with production instance.

Источник

Last updated on: March 10th, 2021

vScope supports both Discovery of and integration with the Active Directory. If something goes wrong you will be prompted with an error message that can give you a hint of the cause to the issue.

The error messages might look something like this:

INVALID_CREDENTIALS: 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580

INVALID_CREDENTIALS: 80090308: LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 775, v1db1

Here is a list of common error codes that might show up:

Further reading

You can read more about integrating vScope with Active Directory on this Knowledge Base post.

Источник

Problem

Users are unable to log in. Nothing has changed in JIRA side.

The following appears in the atlassian-jira.log:

2017-10-25 14:13:07,009 ERROR [scheduler_Worker-3] [atlassian.crowd.directory.DbCachingDirectoryPoller] pollChanges Error occurred while refreshing the cache for directory [ 31064065 ].
com.atlassian.crowd.exception.OperationFailedException: Error looking up attributes for highestCommittedUSN
	at com.atlassian.crowd.directory.MicrosoftActiveDirectory.fetchHighestCommittedUSN(MicrosoftActiveDirectory.java:847)

...

Caused by: org.springframework.ldap.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580 ]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580 ]

Cause

LDAP Error 49 data 52e means that the credentials of the user configured to bind LDAP directory with JIRA are incorrect, as described here: https://confluence.atlassian.com/kb/common-user-management-errors-820119309.html#CommonUserManagementErrors-ActiveDirectoryError49

This can happen when that user is either removed or has its password changed from LDAP side.

Resolution 1

Follow the steps outlined at Restore Passwords To Recover Admin User Rights. By doing so, you’ll be able to access the User Directory settings and change the «Username» field with a valid admin user or change the «Password» field with the new password, allowing JIRA to connect to LDAP.

As an alternative to Recovery Mode, you could utilize auth_fallback by following the guide: Bypass SAML authentication for Jira Data Center 

Resolution 2

Alternatively, you can run the following query against your database to find out which one is the admin account that JIRA uses to connect to the LDAP:

SELECT * FROM cwd_directory_attribute WHERE attribute_name = 'ldap.userdn'; 

Note: The query may return multiple results in case you have more than one User Directory in your JIRA instance.

Re-adding the user back to the LDAP with the same password should resolve the issue.

Resolution 3

As JIRA storing LDAP Login credential in the database without encryption, you may also update those LDAP credential in your database:

lDAP Password Field

Select * from cwd_directory_attribute where attribute_name = 'ldap.password'

LDAP User Name Field

SELECT * FROM cwd_directory_attribute WHERE attribute_name = 'ldap.userdn';

 attribute_value is the fields which storing those data.

  Always perform a backup before you perform edit/update query in the database. It is also highly recommended for you to perform this in a test instance before proceeding with production instance.

Solution ID	sk179755
Technical Level
Product	Identity Awareness
Version	R80.40, R81, R81.10, R81.20
OS	Gaia
Date Created	2022-08-02 00:00:00.0
Last Modified	2022-11-23 03:54:32.0

Symptoms

Cause

Solution