I'm interested in how other people code this because I'm either not understanding it properly or I'm missing something or perhaps even I'm doing it right!
First of all, this is NOT an Active Directory instance of LDAP its OpenDS which other than some syntactical differences shouldn't much matter.
So assume I have my tree structure setup something like this:
-dc=somedomain,dc=com
-uid=rootuser
-ou=Group1
-uid=username1
-uid=username2
-ou=Group2
-uid=username3
-uid=username4
In order to authenticate as the 'rootuser' I would need to pass the fully qualified Username when I create my System.DirectoryServices.DirectoryEntry object, in this case:
uid=rootuser,dc=somedomain,dc=com
but for any other user in the tree I have to know in advance what LDAP path to append to the username to have them authenticate thru. So for example this will fail:
uid=username1,dc=somedomain,dc=com
but this will work:
uid=username1,dc=somedomain,dc=com,ou=Group1
So my question is how do you handle this when you don't know at login time what specific group a user belongs to to build that path? The only way I can figure to do it is to make the initial call as 'rootuser' so I have access to the entire tree then use System.DirectoryServices.DirectorySearcher to scan it for that particular user (i.e. username1)
using (DirectorySearcher searcher = GetDirectorySearcher()) {
searcher.Filter = "(&(objectClass=person)(uid=" + userName+ "))";
SearchResult result = searcher.FindOne();
return result.GetDirectoryEntry().Path;
}
at that point I have the path for the user I want to login and I can proceed with the actual auth. Am I way off base here or is this generally how it is done?
thanks!
You build a search filter on attributes that are unique to the user, e.g. screen-name, e-mail. Make sure LDAP is configured to ensure they are unique. Then you find the corresponding entry if any, get the DN, and rebind as that user with the appropriate password. If there was no such entry you react accordingly.
You don't say what language you are using, but in JNDI that means setting the DN as the security principal, the password as the credentials, and calling LdapContext.reconnect().
SASL supports the notion of using a username to authenticate. Your directory server administrator may be able to configure the directory server to map distinguished names to identities. Given the correct mapping it is possible for a client to authenticate without knowing the distinguished name. Professional-quality directory servers support a number of different mapping mechanisms such as direct mapping, exact match, regular expression, or a custom identity mapper.
Related
Is there any expected/standardized behavior for an app that authenticates via LDAP, when one of its registered users has its DN changed? (Or more generally, when their effective principal changes, which seems to commonly be their DN. I'll say "principal" instead from here, though I usually think "DN".)
Here's an example from Gitlab running into this issue: https://gitlab.com/gitlab-org/gitlab-foss/issues/993
In their case (based on the commit linked in that issue) they seem to address this by using multiple attributes to identify users instead of a single one, so that a single change doesn't prevent them from mapping back to the same LDAP user.
It seems to me the available options would be:
Don't try to prevent the issue but provide some method to change the principal stored (either in-app or via DB modifications)
Try to prevent the issue by picking (automatically or manually by user) a better, static user attribute to use as principal
Try to mitigate the issue by cross-referencing multiple attributes, as in the above links
Which of these would be the expected/"best" approach here, if any?
We have integrated Websphere commerce with LDAP and the proper login flow is working fine.
We have a requirement that user can have an option to login using his phone number and also his membership card.
Currently we are storing the ph.no and membership card in LDAP database also.
We are unable to use these fields for login as well. Can someone give some pointers on the same?
WAS has Standalone and Federated LDAP authentication.
Standalone LDAP configs in WebSphere allow you to construct your own LDAP search that's used to map a web username to a DN. You can list multiple attributes using LDAP filter syntax (|(phone=%v)(membershipcard=%v)...
https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tsec_ldapfilter.html
Modify the user filter, if necessary. The user filter is used for
searching the registry for users and is typically used for the
security role-to-user assignment. The filter is also used to
authenticate a user with the attribute that is specified in the
filter. The filter specifies the property that is used to look up
users in the directory service. In the following example, the property
that is assigned to %v, which is the short name of the user, must be a
unique key. Two LDAP entries with the same object class cannot have
the same short name. To look up users based on their user IDs (uid)
and to use the inetOrgPerson object class, specify the following
syntax: (&(uid=%v)(objectclass=inetOrgPerson)
Federated registries take a semi-colon separated list of LDAP attribute names used for the same purpose.
https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twim_ldap_settings.html :
All login properties are searched during login. If multiple entries or
no entries are found, an exception is thrown. For example, if you
specify the login properties as uid;mail and the login ID as Bob, the
search filter searches for uid=Bob or mail=Bob. When the search
returns a single entry, then authentication can proceed. Otherwise, an
exception is thrown.
Both are covered in gory detail in the manual.
I have specified the LDAP filter option as uid=${username} to get the username. I also need to get other attributes such as organization, telephone no, email etc.. I have only one LDAP store configured in my system. I know all the configuration steps to acheive it. I am struck with the LDAP filter to get those attributes. That's where I am getting error.
for eg, in order to get organization, I should give something like o=${SOMETHING}
How to provide the filter?
Please let me know.
Thanks,
Aswini J
I'm assuming you have already specified in the Assertion Mapping screen that you wish to "Retrieve Additional Attributes" and that you then added your existing LDAP Data Store.
The filter is simply used to locate a single user's record that you wish to return the associated attributes from. In the previous Admin screen (LDAP Directory Search) is where you specify the user attributes you wish to return. You simply specify your LDAP Base DN and then select the attributes from the drop-down list. You can find more information in the Admin Guide -
http://documentation.pingidentity.com/display/PF73/Configuring+an+LDAP+Directory+Search#ConfiguringanLDAPDirectorySearch-2232188
After choosing the attributes, you then get to setup your LDAP Filter where something as simple as "uid=${username}" will usually suffice. It really depends on what user identifier is coming in from your IDP Adapter and how specify that lookup needs to be. If you're using the HTMLForm Adapter, then chances are your users are entering their LDAP userID values.
I have set up a Ldap Server somewhere. I can bind to it, can add, modify, delete entry in the database. Now when it come to authentication isnt it as simple as giving the username and password to the server, asking it to search for an entry matching the two? And furthermore, isnt it the 'userPassword' field that contains the password for a user in there?
Now,
I tried to set up splunk to authenticate from my Ldap server, i provided the username and password, but it failed authentication. Isnt it that 'userPassword' field that splunk checks? What should be the possible reason?
LDAP servers are generally not going to allow you to search on the userPassword attribute, for obvious security reasons. (and the password attribute is likely stored in hashed form anyway, so a straight search would not work.)
Instead, the usual way to do LDAP authentication is:
prompt for username & password
Bind to LDAP with your application's account, search for username to get the full distinguished name (dn) of the user's LDAP entry
Make a new LDAP connection, and attempt to bind using the user's dn & password
(If you know how to construct the dn from the username, you can skip step 2, but it's generally a good idea to search first - that way you're less sensitive to things like changes in the OU structure of the LDAP directory)
Typically you would search using the username value provided on uid or cn values within the LDAP Tree.
-jim
I think this code will help you resolve the issue of authentication. I've answered to resolve the issue. You can check out this Question http://bit.ly/TIJMte
I'm running into a problem using LDAP to authenticate logins.
We are using a Novell edirectory for authentication of other applications like Jira. ( Jira works perfect ).
I have this application that allow these basic LDAP configurations:
My problem is, when I try to log in, it takes my username XXXXXXXX and pre-pends it to the search base as uid. So it tries to log me in as :
uid=XXXXXXXX,ou=people,o=mycompany
Which would work on our Sun LDAP server, but doesn't work on our Novell edirectory LDAP server. edirectory only works when I try to log in as the distinguished name :
cn=XXXXXXXX,ou=people,o=mycompany
Why does edirectory behave like this?
Is it config that we have specified or does edirectory always use cn as distinguished name?
Thanks
I suggest that is is the application that is 'behaving like this', not edirectory. Obviously your edirectoryis structured differently from your Sun LDAP server, yet the application is treating them both the same. LDAP servers only execute queries, they don't construct them. The application does that.
The naming attribute is up to the person making the object. However by default most eDirectory tools set it as cn=. If you want, you can create objects as uid= in your eDirectory. It would be hard to convert existing users.
Many LDAP tools that make this assumption will allow you to specify what the naming attribute might be.
Your app is making a bad assumption.
You can add a UID value on each object, the same as the CN, but that would not help since it is not then a naming attribute.
In other words, if the application was doing a query for (uid=XXXXXXXX) then adding a uid value that matches CN would help.
If however it is doing a bind as a specific user, as uid=XXXXXXXX,ou=users,o=mycompany that won't help.