Acceptsecuritycontext error data 52e v2580

I’m adding LDAP authentication to the spring-boot application. All set accordingly and I’m getting «LDAP error code 49 AcceptSecurityContext error data 52e v2580» error even after providing correct credentials.

I’m using import javax.naming.Context; and have mentioned the code below.

String url = ldap_url;
String domain = ldap_domain;
String uname = request.getUsername();
String pwd = request.getPassword();
boolean authentication = false;
boolean error = true;
String msg;
String ldapSearchBase = "OU=TEST_OU, DC=DC2, DC=DC1";

// create env for initial context
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, url);
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "CN=" + uname + "@" + domain + "," + ldapSearchBase);
env.put(Context.SECURITY_CREDENTIALS, pwd);
NamingEnumeration results = null;

try {
    LdapContext ctx = new InitialLdapContext(env, null);
    authentication = true;
    error = false;
} catch (NamingException e) {
    logger.error("LDAP error for :{NamingException}" + e);
    return ResponseEntity.ok(new ApiResponse(true, e.getMessage()));
} finally {
    if (!error) {
        msg = "Login success!!!";
    } else {
        msg = "Authentication failed!";
    }
}

logger.info("exitinig...");

if (authentication) {
    return ResponseEntity.ok(new ApiResponse(false, msg));
} else {
    return ResponseEntity.ok(new ApiResponse(true, msg));
}

Error is catching as NamingException.

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.

Hi All,

While trying to sync users in Ambari with AD getting following exception:

[root@ip-172-10-31-216 keytabs]# ambari-server setup-ldap

Using python  /usr/bin/python

Setting up LDAP properties...

Primary URL* {host:port} (172.10.138.164:389):

Secondary URL {host:port} :

Use SSL* [true/false] (false):

User object class* (person):

User name attribute* (sAMAccountName):

Group object class* (group):

Group name attribute* (cn):

Group member attribute* (member):

Distinguished name attribute* (distinguishedName):

Base DN* (ou=usercn,dc=testad,dc=com):

Referral method [follow/ignore] :

Bind anonymously* [true/false] (false):

Handling behavior for username collisions [convert/skip] for LDAP sync* (convert):

Manager DN* (cn=testhdp,ou=admincn,ou=testad,dc=com):

Enter Manager Password* :

Re-enter password:

====================


Review Settings

====================

authentication.ldap.managerDn: cn=testhdp,ou=admincn,ou=testad,dc=com

authentication.ldap.managerPassword: *****

Save settings [y/n] (y)? y

Saving...done

Ambari Server 'setup-ldap' completed successfully.




[root@ip-172-10-31-216 keytabs]# service ambari-server restart

Using python  /usr/bin/python

Restarting ambari-server

Waiting for server stop...

Ambari Server stopped

Ambari Server running with administrator privileges.

Organizing resource files at /var/lib/ambari-server/resources...

Ambari database consistency check started...

Server PID at: /var/run/ambari-server/ambari-server.pid

Server out at: /var/log/ambari-server/ambari-server.out

Server log at: /var/log/ambari-server/ambari-server.log

Waiting for server start................

Server started listening on 8080

DB configs consistency check: no errors and warnings were found.




[root@ip-172-10-31-216 keytabs]# ambari-server sync-ldap --all

Using python  /usr/bin/python

Syncing with LDAP...

Enter Ambari Admin login: admin

Enter Ambari Admin password:

Syncing all...ERROR: Exiting with exit code 1.

REASON: Caught exception running LDAP sync. [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]

[root@ip-172-10-31-216 keytabs]#

How to resolve it?

Attached AD scrreshots ad1.png ad2.png

Please suggest.

Thanks,

Bhushan

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.

Источник

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.

Источник

Confluence Support

Get started

Knowledge base

Products

Jira Software

Project and issue tracking

Jira Service Management

Service management and customer support

Jira Work Management

Manage any business project

Confluence

Bitbucket

Git code management

Resources

Documentation

Usage and admin help

Community

Answers, support, and inspiration

System Status

Cloud services health

Suggestions and bugs

Feature suggestions and bug reports

Marketplace

Billing and licensing

Frequently asked questions

Viewport

Confluence

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

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 Confluence side.

The following appears in the atlassian.confluence.log:

Cause

LDAP Error 49 data 52e means that the credentials of the user configured to bind LDAP directory with Confluence 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 Confluence 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 Confluence uses to connect to the LDAP:

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

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

Источник

Comment acceptsecuritycontext error data 52e v2580

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 compatibility with Azure AD Domain Services #869

Comments

afawaz2 commented Nov 15, 2020

The ldap module is returning «invalid credentials» when attempting to bind to the ldap of Azure ADDS.

I attempted to debug the issue using the php snippet in #599. That case the bind was successful when the name in the bind request only had the username without the DN and without «cn=username» or «uid=username.»

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

freescout-helpdesk commented Nov 15, 2020

Are you using Office 365?

stevebauman commented Nov 15, 2020

Well need much more information to help you debug this. A start would be your LDAP configuration (with any sensitive details omitted), as well as your Azure ADDS configuration.

I would also suggest testing basic connectivity to ensure your server is reachable from your web server, then debug from there.

freescout-helpdesk commented Nov 15, 2020

afawaz2 commented Nov 15, 2020

I used the bind dn as: «ou=AADDC Users,dc=aad. «

Well need much more information to help you debug this. A start would be your LDAP configuration (with any sensitive details omitted), as well as your Azure ADDS configuration.

I would also suggest testing basic connectivity to ensure your server is reachable from your web server, then debug from there.

I can reach the ADDS from the server. What information about the ADDS would you need? I can send those in a private email.

LDAPS is enabled, but the module was failing to connect with the TLS option «Can’t contact LDAP server.»

I switched to plaintext with a 389 port. I can see the traffic between the server and the ldap with tcpdump.

The request is:
bindRequest(1) «cn=ldap_service,dc=xxxxxxx,dc=com» simple

The response is:
bindResponse(1) 1X80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, data 52e, v2580

stevebauman commented Nov 15, 2020 •

That response error code (52e) means:

Indicates an Active Directory (AD) AcceptSecurityContext error, which is returned when the username is valid but the combination of password and user credential is invalid. This is the AD equivalent of LDAP error code 49.

Try resetting the service accounts password to ensure you’re using the correct one. Also ensure that all account flags are clear (i.e. user account locked out, user must change password on next login, smart card required, etc.)

I don’t think we’ll need to see your configuration since you mentioned you’re getting a response from your server (I see that you mentioned this in your original post, my mistake!).

You could also try binding with a domain admin account just to ensure there’s no permission issues taking place.

Let us know how the troubleshooting goes!

afawaz2 commented Nov 16, 2020

I am getting the same error. I tested multiple types of users and confirmed that non of them are locked out. Is this module using the https://github.com/Adldap2/Adldap2-Laravel project?

Where can I find the module’s source code in my server? The modules folder is empty in /assets/install. I am using the docker container, https://github.com/tiredofit/docker-freescout.

freescout-helpdesk commented Nov 16, 2020

Where can I find the module’s source code in my server?

afawaz2 commented Nov 16, 2020 •

Thank you for the link, it turns out that you have two admin prefixes set cn= and uid=, looking at the ADDS documentation for the bind request
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/6a5891b8-928e-4b75-a4a5-0e3b77eaca52

AADS expects allows the use of the full DN to do the match so instead of using the username (sAMAccountName) to do the login, I was able to bind use the CN.

For anyone in the future attempting this, install active directory explorer onto a joined machine and find the full DN of the user. The ldap module sets the bindrequest using «CN=,«

Источник

Как устранить ошибку. Учетные данные недействительны на сервере LDAP

Я добавляю аутентификацию LDAP в приложение с весенней загрузкой. Все настроено соответствующим образом, и я получаю сообщение об ошибке «Код ошибки LDAP 49 AcceptSecurityContext error data 52e v2580» даже после предоставления правильных учетных данных.

я использую import javax.naming.Context; и упомянули код ниже.

String url = ldap_url; String domain = ldap_domain; String uname = request.getUsername(); String pwd = request.getPassword(); boolean authentication = false; boolean error = true; String msg; String ldapSearchBase = 'OU=TEST_OU, DC=DC2, DC=DC1'; // create env for initial context Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, 'com.sun.jndi.ldap.LdapCtxFactory'); env.put(Context.PROVIDER_URL, url); env.put(Context.SECURITY_AUTHENTICATION, 'simple'); env.put(Context.SECURITY_PRINCIPAL, 'CN=' + uname + '@' + domain + ',' + ldapSearchBase); env.put(Context.SECURITY_CREDENTIALS, pwd); NamingEnumeration results = null; try { LdapContext ctx = new InitialLdapContext(env, null); authentication = true; error = false; } catch (NamingException e) { logger.error('LDAP error for :{NamingException}' + e); return ResponseEntity.ok(new ApiResponse(true, e.getMessage())); } finally { if (!error) { msg = 'Login success!!!'; } else { msg = 'Authentication failed!'; } } logger.info('exitinig...'); if (authentication) { return ResponseEntity.ok(new ApiResponse(false, msg)); } else { return ResponseEntity.ok(new ApiResponse(true, msg)); } 

Ошибка улавливается как NamingException.

Ответ об ошибке с кодом ошибки LDAP 49 … data 52e «Возвращает, если имя пользователя действительное. но пароль / учетные данные недействительны.’

Могут возникнуть проблемы с инфраструктурой, например, когда учетная запись компьютера контроллера домена не может быть синхронизирована с центром распространения ключей (KDC). Однако, когда существует это условие, у вас, вероятно, будет гораздо больше других проблем.

• Спасибо за ответ. Я не могу понять ошибку, указав это как проблему с учетными данными. Я сомневаюсь в SECURITY_PRINCIPAL.
• Возможно, вы захотите получить заведомо хороший браузер LDAP (или использовать утилиту ldapsearch) для проверки ваших параметров. (Мне нравится Apache Studio). Код результата LDAP. Вы можете попробовать использовать имя userPrincipal для входа ([email protected]) вместо DN. Иногда причиной является неправильное экранирование DN, но я предполагаю, что вы получите другой код результата, если имя пользователя будет неправильным.

Это может произойти, если для входа в вашу учетную запись требуется смарт-карта.

В Active Directory есть параметр «Смарт-карта требуется для интерактивного входа в систему».