AD authentification

[damirmiljkovic]

I am trying to authenticate agains AD using Android app but it doesn't work, I am probably missing something. What should I enter in Bind DN, I have tried entering username alone, "CN={username}", "CN={username},CN={group},DN={domain name}" none of these work I am always getting:

LDAPException(resultCode=49 (invalid credentials), errorMessage='80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1��', diagnosticMessage='80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1��')

I am 100% positive that credentials are not invalid because I tried using other app and it worked. Could you please help me with this.

[bertold]

The "CN={username},CN={group},DN={domain name}" will not work as you have DN in this string. By default, Active Directory users are under CN={username},CN=Users,DC=example,DC=com (where example.com is your Active Directory domain).

[damirmiljkovic]

I used quotation marks just to distinguish what combinations I tried I didn't use quotation in app, but it still didn't work. BTW do I need to set group?

[bertold]

Bear in mind that this is not an Active Directory support group ;-) We do use the UnboundID LDAP SDK to connect to Active Directory on a daily basis. You do not need quotation marks, but you may need to double check the distinguished names in general. The best would be to try some tools like ldp.exe that will show you the distinguished names.

[lr]

For Active Directory, the best thing to use for authentication is userPrincipalName, or UPN. It is an attribute where the value is in the form of @<some fully-qualified domain configured in your active directory> (without the <>).

You can use DN, but in Active Directory, users can move around a lot, so it is a moving target. If you use DN, then you usually have to query AD first with an admin bind to look the user up so that you can get the DN.

The third way to authenticate a user to Active Directory is to use <active directory domain>\ (without the <>).

UPN is Microsoft's recommended way of doing authentication, and you can see this in their recommendations for authenticating to services via ADFS (like to Office 365, for instance).

-lucas

On Thu, Jan 5, 2017 at 8:28 AM, damirmiljkovic notifications@github.com wrote:

I used quotation marks just to distinguish what combinations I tried I didn't use quotation in app, but it still didn't work.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/UnboundID/ldapsdk/issues/22#issuecomment-270643757, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIIxXWyzzLMW5qBgOTIUOIQT8m_a3oZks5rPO_ngaJpZM4LbiXa .

[lr]

I should note that, although MS has recommended using UPN since around 2003, it is not a required attribute. You can read about it here:

https://msdn.microsoft.com/en-us/library/ms680857(v=vs.85).aspx

-lucas

On Thu, Jan 5, 2017 at 9:26 AM, Lucas Rockwell lr@lucasrockwell.com wrote:

For Active Directory, the best thing to use for authentication is userPrincipalName, or UPN. It is an attribute where the value is in the form of @<some fully-qualified domain configured in your active directory> (without the <>).

You can use DN, but in Active Directory, users can move around a lot, so it is a moving target. If you use DN, then you usually have to query AD first with an admin bind to look the user up so that you can get the DN.

The third way to authenticate a user to Active Directory is to use <active directory domain>\ (without the <>).

UPN is Microsoft's recommended way of doing authentication, and you can see this in their recommendations for authenticating to services via ADFS (like to Office 365, for instance).

-lucas

On Thu, Jan 5, 2017 at 8:28 AM, damirmiljkovic notifications@github.com wrote:

I used quotation marks just to distinguish what combinations I tried I didn't use quotation in app, but it still didn't work.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/UnboundID/ldapsdk/issues/22#issuecomment-270643757, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIIxXWyzzLMW5qBgOTIUOIQT8m_a3oZks5rPO_ngaJpZM4LbiXa .

[damirmiljkovic]

Thank you both for your help but I still don't get what I have to enter in Bind DN and Base DN fields to authenticate assuming my username is damir, password is 1234 and domain name example.com.

[dirmgr]

The official LDAP specification in RFC 4511 section 4.2 states that the bind request must be a DN. Active Directory violates this and allows you to provide values that aren't valid DNs, but I'm not familiar enough with what Active Directory calls LDAP to know exactly what formats are allowed.

I think that Active Directory DNs are typically in the format "cn=First Last,cn=Users,dc=example,dc=com", but using cn as a naming attribute is not a great idea, and I have no idea how AD handles multiple users with the same first and last name.

Also, the domain portion at the end of the DN may include a subdomain. However, the server should allow you to perform an anonymous search to retrieve the root DSE (the entry whose DN is the empty string) and request the namingContexts attribute to see what base DNs the server uses. To do this with the ldapsearch tool that the LDAP SDK provides, you can use a command like:

tools/ldapsearch --hostname {server-address} \
     --port 389 --baseDN "" --scope base \
     "(objectClass=*)" namingContexts

And if nothing else helps, then the best thing to do might be to ask your administrator what the DN is for your entry.

[damirmiljkovic]

Once again thank you very much for all your help but my conclusion is that I can't use this app https://play.google.com/store/apps/details?id=com.unboundid.android.ldap.client to authenticate on domain controller only with my username and password or sAMAccountName, because if I enter something like username@domain.com app gives me an error saying that it requires equal sign.

[dirmgr]

If the problem is that the app won't allow you to use a non-DN value in those fields, then you could just edit the app code (especially if you're compiling it anyway) to remove that constraint. Just take out the blocks that try to create DN objects from the bindDN and baseDN values at the bottom of ServerInstance.isDefinitionValid.

[damirmiljkovic]

Yes problem was that app is not letting me use non-DN value. I did what you suggested and it is working.