One of our customer will switch the authentication from LDAP to integrated Windows authentication(IWA). But I don't know exactly what the differences are between them in a programmer's view. How does integrated Windows authentication work? What are the advantages using IWA over LDAP?
Windows authentication is OS-based authentication which involves Windows' verification of user supplied principal (e.g., username, ID, etc.) and credentials (e.g., password, biometrics data, etc.) against its user registry, which is probably local. LDAP is a protocol (and an IETF standard) that defines elements, controls, and operations to access directory services. One of the LDAP operations is called a "bind" which can be "simple" or "SASL." Simple LDAP binds can be anonymous, unauthenticated, and authenticated (i.e., distinguished name and password). The result of an LDAP "authenticated bind" or "SASL bind" is what you called "generic LDAP authentication." Please see RFC 4511 and 4513 for more on how LDAP "bind" works. Local OS authentication is probably faster and more reliable (in terms of high availability as the user registry is locally stored and always available). However, OS user registries are not easy to maintain and extend if the number of users is large. An LDAP directory service can act as a single, authoritative user registry for thousands of users and can be accessible to many applications, middleware, and systems (h/w and/or OS) without requiring proprietary libraries or access schemes. Many OS' can be configured including Windows to use an LDAP directory as their user registry for more efficient identity management.
One more reason can be:
To authenticate Mac and Linux users in the organization we cant use windows authentication
Related
So i'm tasked with implementing SSO for our Windows application. Currently, after a user logs into the machine, he or she has to re-log in to our app when he or she loads the application. The application validates the user by querying a LDAP server.
What we're looking to have is for the user to automatically be logged into the app when they click on it. My understanding is that the LDAP authentication must still happen, but Im not exactly sure what the workflow would be, and how exactly we can validate a user without requiring them to re-enter a username / password. Note that this is not a web application so I can't use tools like SAML or OAuth (unless i'm mistaken about this too..?)
So my specific question is as follows:
Is it possible to use LDAP for SSO, and if so, how? Is it possible for me to authenticate a user with just his or her username, or is a password also required?
Any guidance would be appreciated, and am happy to provide further clarification if needed.
First of all, LDAP is a protocol, which you use to communicate with databases that implement this protocol.
So LDAP databases (commonly called directories) are ... databases and so do not provide SSO functionality.
To deploy a SSO solution, you need a SSO service. All your applications will have to be "compliant" with this service in a way or another.
The only way I can think of to make a "Windows SSO" without adding a third party application is that the applications can retrieve NTLM informations in requests made by the client and uses the user data to identify him. (but in term of security, I let you judge what you think about it ;) ) . See this php example
Some LDAP implementations, including OpenLDAP, provide some level of support the Generic Security Service Application Program Interface (GSSAPI) or SPNEGO (a specific GSSAPI implementation)
Although not trivial, it is possible to perform SSO from a "browser" that supports GSSAPI. AFIK, IE, Firefox, Safari and Chrome all provide some level of support for GSSAPI although each browser requires specific configuration (typically whitelisting of Servers).
There are many SSO Products that implement these features in a "probably" more secure and easier process than doing it yourself.
There are many known vulnerabilities details that have been exploited with GSAPPI/SPNEGO typically due to implementation issues.
I am in the preparation phase of testing an application that will be using LDAP for user authentication. What are some tips or advice you might have for this endeavor?
I don't have a great understanding of LDAP but I believe all that will be used is the application client calls to LDAP with a username and sees if the password matches. Is that an accurate description? Also, what are some edge cases to test? Thanks.
LDAP authentication is often (but not always) a 2-step process: first the application does an LDAP query to locate the "distinguished name" (dn) of the account the user's trying to authenticate to, then it tries to log in ("bind", in LDAP parlance) as that dn, using the user-supplied password.
If the "bind" attempt works, the application knows the password is correct. (The LDAP server is likely not configured to allow the application to actually extract the password and do the comparison itself, for obvious security reasons).
An LDAP-enabled application will typically require a way to configure:
hostname/port of LDAP server
search base (e.g., dc=mycompany,dc=org)
user search filter (e.g. "(|(cn=%userid)(mail=%userid))")
application credentials for the initial LDAP query (unless the server allows anonymous queries)
You will most likely need to support SSL, so you don't send the user's password to the LDAP server in cleartext.
This strongly depends on your technology.
If you are directly querying the ldap you have to care about performance e.g. how fast are your queries, how often you have to do them and if you server is sized appropriately.
If you are using some kind of container that it providing SSO then these will usually have some caching features, etc.. There you have to check if everything is working properly.
You would need ldap_connect and ldap_bind functions. Also once you are binded with the ldap server you can search for entries on the ldap and get the user information.
You should surely check if encodings are handled properly (try umlauts or other weird stuff in passwords).
And take care to test with the LDAP servers you care about, Active Directory, OpenLdap, Apaches LDAP Server, and a few others, they might show different behaviours.
Also check if the client handles 'referrals' correct, e.g. when you try to lookup users in a different domain (e.g. two AD forrests with forrest trust installed).
Several sites, including this one, are using OpenID to authenticate their users. And of course, OpenID is a good solution to manage user accounts, simply by linking them to their OpenID account.
But are there similar solutions that could be used for desktop applications? I know there's CardSpace, where you create a custom ID card to contain your identity and optionally protect it with a pincode. But are there more alternatives for authentications on a desktop system or on systems within a local intranet environment?
And yes, I can write my own system where I keep a list of usernames and (hashed) passwords and then build my own login system but I just hate to invent my own wheel, especially when I need to keep it secure.
I would recommend that you look into the option of building an STS (using WIF, aka Geneva) and use (active) WS-federation in your windows app. Or if you can wait that long, just use Geneva Server when that is released.
We have a solution that works more or less like this:
Desktop tool prompts the user for ID/password
Desktop tool sends the ID/password over an encrypted (SSL) channel to the server.
Server initiates an HTTP request to a known URL of a login form and inputs the username and password as if they were form fields.
If the HTTP server responds appropriately, the server accepts the client as authenticated.
The target of that HTTP request should be tied to whatever single sign-on system that you use for the web application environment. In our case it happens not to be OpenID but it could be.
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.
Is it possible to instruct the jabber/xmpp server to delegate authentication to another module? We are building an internal application using XMPP and it would be fantastic if we could let users keep their standard username/password that they use in our web-apps. The web-apps are currently hashing passwords, and so the passwords in the DB are not stored in plain-text form. It would have been easy to share passwords across systems if this were not the case, but then, of course, storing plain-text passwords in the server-side database is a big no-no.
Ideally we could just tell the jabber server "hey, just pass off your username/authentication request to here" and have some other process running (perhaps even just an xmpp bot?) that handles authentication.
We are currently using ejabberd as our server, which I believe is written in Erlang. We're not tied to ejabberd though. I know that XMPP is huge, and largely extensible - but I haven't found anything about extensible authentication on the server side.
I found this on the XMPP website, but that appears to be the protocol for negotiating authentication between the client and the server, not the actual authentication mechanism on the server.
Any pointers on how to merge authentication schemes between an XMPP server and our other systems?
ejabberd has multiple ways to authenticate. You can use LDAP, for example, if you have an LDAP server for your organisation. This works at my company, and provides a single log in for our wiki, ticket system, etc.
Have a look at the section on authentication in the user guide.