- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-17-2014 05:29 PM
We are attempting to integrate a customers instance with LDAP (AD, using LDAPS) and have had a mixture of success and failure.
We are able to Browse and import records from the AD server without trouble but Authentication is returning the same error for all accounts tested, even after the password is changed in AD and the changes are verified to have been replicated to the target AD server.
[LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]
According to some IBM documentation (IBM Data codes related to 'LDAP: error code 49' with Microsoft Active Directory - United States) the closest error explanation is:
80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 52e, v893
HEX: 0x52e - invalid credentials
DEC: 1326 - ERROR_LOGON_FAILURE (Logon failure: unknown user name or bad password.)
NOTE: Returns when username is valid but password/credential is invalid. Will prevent most other errors from being displayed as noted.
Has anybody else had this problem or can someone suggest the next steps towards resolution?
Thanks in advance for your assistance.
Solved! Go to Solution.
- Labels:
-
Integrations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-18-2014 11:14 AM
Service-now tech support were able to assist us with this issue which is now resolved. Like most problems the answer seems ridiculously simple and even logical once pointed out.
We had set the DN Field to User ID - it should either be blank or set to Source.
I could not find this documented (may well be, though) but it would seem that this field tells the integration which user record field to use to find the name of the node against whicha bind should be attempted to authenticate a user.
Like I say, even quite logical, once you know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-18-2014 11:14 AM
Service-now tech support were able to assist us with this issue which is now resolved. Like most problems the answer seems ridiculously simple and even logical once pointed out.
We had set the DN Field to User ID - it should either be blank or set to Source.
I could not find this documented (may well be, though) but it would seem that this field tells the integration which user record field to use to find the name of the node against whicha bind should be attempted to authenticate a user.
Like I say, even quite logical, once you know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-29-2016 10:20 AM
Hi David,
I am having this exact issue. I am not sure I understand what you mean by set the DN Field to User ID - it should either be blank or set to Source.
So are you talking about the attributes for the dn field on the ldap_server_config? They are set to: table=sys_user,allow_null=true . So what exactly are you saying to set them to?
Any help would be greatly appreciated.
Thanks,
Calisse
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-17-2018 12:29 AM
Hi Calisse,
Sorry for the late reply, but I want to document that we had the same issue.
If you open the ldap_server_config table, there is a DN Field column (dn_field).
In our scenario, we had a working LDAP server, and one that wasn't.
The one that was working was set to blank.
The one that wasn't working was set to 'source'.
Setting dn_field on the LDAP server that wasn't working to blank allowed users to authenticate against it.