I am using MarkLogic version 8.04 on CentOS 6. I am trying to do external authentication/authorization using LDAP.
I've created an external security authentication object:
name ldap-config-simple
authentication ldap
authorization ldap
ldap server url ldap://<my server address>:389
ldap base ou=<mycompany>,dc=<info>,dc=<my org>
ldap attribute sAMAccountName
ldap default user cn=<user id>,ou=xxxx,ou=yyyyy,dc=<info>,dc=<my org>
ldap bind method simple
and associated it with an HTML App server (here are the pertinent settings):
authentication basic
internal security true
external security ldap-config-simple
And I have associated an LDAP group to a role (here are the pertinent settings):
external name cn=marklogic,ou=groups,dc=<info>,dc=<my org>
The problem is that authentication fails when I try to access the App server using my LDAP user. The log for the external LDAP server shows that the search string that MarkLogic sends looks like this:
(member=cn=marklogic,ou=groups,dc=<info>,dc=<my org>)
But the LDAP server is expecting the search to be:
(memberOf=cn=marklogic,ou=groups,dc=<info>,dc=<my org>)
The LDAP Server admin assures me that "memberOf" is the accepted standard for this type of query. We are using an OpenLDAP server - it is a pretty standard LDAP installation. Is there a way to have MarkLogic send "memberOf=" for the search rather than "member=" ?
Note that I was able to authenticate with my LDAP user ID through the App Server when I associated my user's DN in the LDAP server to a configured MarkLogic user. But I would prefer to use the Role based authentication since that puts the access controls in the LDAP server.
Any help appreciated.
Answering my own question. It is working now with the configuration above - although I didn't make any changes. MarkLogic support told me that a previous configuration may have been cached. In the process of debugging this I did a network packet trace to see exactly what MarkLogic was sending and it looks like it actually requests both the "memberOf" and "member" groups - I guess the LDAP admin only saw the latter in the logs.
Related
I have configured LDAP server but i am facing problem to bind user and also not able to authenticate user using PHP, I have used this code.
https://gist.github.com/theredstapler/f440d9cf19c03094e6627cfca6aa1d8a
instead of example I used our server Details.
I'm a newbie in the LDAP + Liferay + OpenAM world, so I wonder if someone could point me in the right direction in a problem I have. In a real life environment, there are 2 LDAP servers, a OpenAM server and a Liferay application. What the customer needs is to authenticate users in Liferay against OpenAM, and OpenAM should use the LDAP servers. Problem is, the user exists only in one of the LDAP servers (it will be moved from one to the other in one point of the future). What the customer wants is:
Users must be able to authenticate independently of what LDAP contains the user.
The obtained token must be valid for both LDAP servers, as it will be used in a different service (I have no control over it) against only one of them to validate authentication.
As I said, I'm new to this world so, if the answer is too complex (I'm afraid it will be for me), maybe you could point me to books or docs that could resolve this scenario.
Thanks
You should configure LifeRay to use OpenAM for all authentications and you can configure OpenAM to use both LDAP servers (use different realms).
Details for OpenAM configuration will be in the OpenAM documentation.
As the previous answer states you should route all your authentication requests to the OpenAM server and let it validate the credentials against the right LDAP server. Using two different realms (one for each LDAP server) won't work in your case since that will require LifeRay to know where to find the user before hand. Also, sessions are linked to a specific realm.
There are multiple solutions to your problem. Here are just a couple:
Option 1
If you have control over the authentication flow. That is, if your application uses a custom UI and communicates with OpenAM via REST, you could create two different authentication module instances under a single realm (let's say two instances of the DataStore authentication module) each one pointing to a different LDAP server.
Let's call this module instances DataStore1 and DataStore2. Your application can collect the user credentials (username and password) and submit them to DataStore1. If authentication succeeds the user is already logged in. If it fails, the application can try with DataStore2.
Of course this is not ideal since you'll be making two authentication requests per login instead of just one.
Option 2
A better option (though more complicated to implement) would be creating a custom authentication module. This module can try authenticating the user against LDAP Server 1 and then try with LDAP Server 2 if the first authentication failed. Notice that with this option you don't need custom logic on the application side since it will only send a single authentication request to the OpenAM server. In fact, you can protect your application with an OpenAM Policy Agent.
Another advantage of this approach over Option 1 is that you can migrate your users behind the scenes assuming that the end goal is to migrate users from LDAP Server 1 to LDAP Server 2. If the first authentication succeeds your custom code could read the user entry from LDAP Server 1 and copy it over to LDAP Server 2.
Hope this helps you solve the problem.
I'm trying to browse the embedded ldap server of WSO2 Identity Server thanks to a LDAP client.
I didn't change the default configuration and I connected successfully as uid=admin,ou=Users,dc=wso2,dc=org.
But then, I don't see the other users I created thanks to WSO2 IS console.
Where and how can I see how the users are stored in the embedded ldap server?
With the default configuration, WSO2 Identity Server get connected to the embedded LDAP server using the user uid=admin,ou=system. And, users will be created in ou=Users,dc=wso2,dc=org and groups will be created in ou=Groups,dc=wso2,dc=org.
Did you create the user uid=admin,ou=Users,dc=wso2,dc=org ?
Use the ldapsearch command line tool or an LDAP browser.
see also
Using ldapsearch
this is my first time trying spring security and ldap. I have couple of novice questions. My main confusions are:
How do we assign roles to users? Is it done on ldap server? or done via a configuration file in my webapp? By roles I mean, Couple of users would have all the access to webapp features(Admins), Regular users (Read only access to webapp data), Analytic group (Users which can run a report in webapp)
Currently application uses j_security_check for normal user authentication with ldap server. (Where is Websphere do we hook up ldap connection settings for this authentication?)
I found it confusing too, and developed my own module which ties in with Java EE Security.
Basically the webapp is set up with standard Java EE Security, and methods on spring beans can be given the #RolesAllowed annotation, in which case the logged in user's roles are checked against the required roles just before calling the method. See here for details.
You can use LDAP or a database or a file - where the roles and users are stored is up to you. Normally for production, you will use LDAP or a connector to some kind of directory server. Sorry I can't help with WebSphere - been a while since I set it up for security.
I have a web application (PHP, but doesn't matter). It uses LDAP for authentication (already working), and it allows users to search LDAP (already working).
But when searching, I use a generic process account to bind() and then run the search().
What I would like is to use the LDAP account that logs in to be the same account that binds for the searching. But the only way I see to do that is to store the user's credentials in the sessions (bad!).
Nutshell: can I get a "state/session/??" token from LDAP, to bind() and then search() on subsequent http requests?
(btw, using Active Directory.)
Basic LDAP doesn't provide anything like this. The credentials that you present when binding are used for the rest of the connection, so if you could keep an LDAP connection open across multiple HTTP requests (and share LDAP connections among however many server jobs you have running), then you could avoid saving credentials.
There are various extensions to LDAP floating around (including several within Active Directory), so it's possible that one of those adds sessions-across-connections, but if so, I'm not aware of it.
As a sort-of-workaround, because Active Directory supports GSSAPI and because of how Kerberos works, you ought to be able to use the user's credentials to request a Kerberos ticket for accessing LDAP then store that ticket as your "state/session/??" token. This Kerberos ticket would only be valid for accessing LDAP and would auto-expire, so this would avoid the pitfalls of storing the user's credentials in the session. I don't know if your LDAP library supports GSSAPI and would give you enough control to do this or not.