I have some understanding problems of LDAP.
When i use an Active Directory Server i can bind with username#domain and a password.
When i use ApacheDS i must give it the full DN of the user and a password.
So i have the folowing Questions:
How do i find out the full dn of a User on a ApacheDS Server with
anonymous privilegs and only the knowledge of username, domain (and
password)?
Is this evenposible? Is the ApacheDS Server even made to be an
alternative to Active Directory?
Generally, LDAP authentication is done in two steps:
Map a given unique user identifier (uid) to its distinguished name using a search operation with a filter like (&(objectClass=user)(uid=%s))
Use a bind operation with that dn to authenticate against your LDAP server.
Active Directory comes with a convenience feature: You can bind using a couple of supported identifiers and AD will do the mapping internally for you.
ApacheDS isn't a plug-and-play substitute for AD, but it's extensible. A Java developer can easily write an authentication interceptor providing the same internal mapping as AD.
As marabu said you can simulate the authentication using a search on the directory before doing the bind.
You can also look for SASL authentication which provides other ways to authenticate.
Here are a list of ApacheDS supported SASL mechanism : http://directory.apache.org/apacheds/advanced-ug/4.1.2-sasl-authn.html
Related
We can create objects like Users and Groups via LDAP.
The question is how to create keytab file using LDAP?
I need somehow to run the following command and obtain the ffs.keytab file using LDAP.
ktpass -princ HTTP/xyzid.xzu.io#DC.YOURADDOMAIN.LINK -mapuser
ffs#DC.YOURADDOMAIN.LINK -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass
+rndPass -out c:\ffs.keytab
What do you think about Kerberos.NET? This library contains several features for integrate LDAP with dot net core applications, include create keytab files. Here have one thread commented by Steve Syfuhs, principal contributor of this library.
LDAP is a protocol to access the directory but it cannot be used to run some command on the server. So the answer for your question is you cannot create keytab using LDAP
For better understanding the use of Kerberos and LDAP, check the below link
https://stackoverflow.com/a/46188971/3496666
You can create objects like users and groups using LDAP because it was the actual purpose for LDAP designed to access the directory and make the changes within the directory whereas keytab is mainly used for authentication and getting auth ticket without the need for password.
If you could explain the purpose for your requirement, some may have solution for you in different way but not using LDAP.
What works
I developed this against our company's AD:
#Bean
public AuthenticationProvider adProvider() {
ActiveDirectoryLdapAuthenticationProvider adProvider = new ActiveDirectoryLdapAuthenticationProvider(
adConfig.getDomain(), adConfig.getUrl(), adConfig.getRootDn());
adProvider.setSearchFilter(adConfig.getSearchFilter());
adProvider.setUseAuthenticationRequestCredentials(true);
adProvider.setConvertSubErrorCodesToExceptions(true);
adProvider.setAuthoritiesMapper(authorities -> List.of(new FooAuthority("*")));
return adProvider;
}
This does work; I can log in using my company credentials. Important: I can use my sAMAccountName (which happens to be my uid as well) to log in.
Goal
Now I want to have some automated tests for certain edge cases, using a local AD. I chose ApacheDS for its cross platform availability, plus it has some Docker containers available. I use openmicroscopy/apacheds
, because it seemed active, documented and configurable, important for a rookie like me.
Problem
The problem is, I cannot log in. I traced it down to two lines in o.s.security.ldap.authentication.ad.ActiveDirectoryLdapAuthenticationProvider: while searchForUser(ctx, username) in doAuthentication(...) (line 148 in 5.0.12.RELEASE) works with my sAMAccountName (like foobar), contextFactory.createContext(env) in bindAsUser(...) (line 204 in 5.0.12.RELEASE) requires a fully qualified DN (like cn=foobar,ou=people,dc=acme,dc=com) to work.
So it seems there is some misconfiguration on my side, probably because of my misunderstanding... Seems I do need some different user to authenticate than to search afterwards? How do I configure this, and/but why does our company's AD works just fine? PS: I read about anonymous authentication, maybe our company allows such? But using Apache Directory Studio against the company's AD requires me to log in (as far as I can tell)...
LDAP based simple BIND operation always requires the distinguished name (DN) of the entry and password. Only AD allows to perform the BIND operation with samAccountName. AD is somewhat special.
I'm currently using mod_authnz_ldap to enable HTTP Basic Authentication against Active Directory for a VirtualHost. Based on the documentation it is recommended to set a user and password to enable the resolving of user DNs for the bind.
However AD offers methods to bind users without using a separate account for searching the directory in front. E.g. you can suffix a username with the Domain like that: username#domain and AD resolves the DN behind the scenes.
As I don't want to create accounts for my web servers I'm curious if there is a way to configure Apache2 using mod_authnz_ldap or another module to bind against AD without using an search account.
You can take advantage of the supported Active Directory object name forms for a simple bind, and skip the search for a user's DN by using directive AuthLDAPInitialBindAsUser with module mod_authnz_ldap.
I want to know the best practice for authenticating users using OpenLDAP. I could perform a search using the cn.
But then what if I got multiple hits with similar cn (under different ancestors of course) and they all use the same password?
I tried to use uids but then I got some types of accounts that do not use uids (like mail accounts and the admin cn). Also, when I added some users under the admin cn (which has no uid) I could not login with the admin cn.
What is the unique key that identifies a user?
Note: I am using phpldapadmin to manage the active directory, and openldap for the c++ code.
You can configure your OpenLDAP server to perform the uniqueness check on your chosen attribute. CN is not the most favorable attribute to choose for uniqueness I would choose UID attribute and have a policy in place for username generation.
[Rewriting my question based on comments]
My DN in Active Directory is "CN=Jesse Barnum,cn=users,dc=360works,dc=com".
I'm writing a web application which attempts to bind to the LDAP server, using the username and password of the active user. When doing the bind, I use the format "CN=$loginName$,cn=users,dc=360works,dc=com". Therefore, my users need to type in their full name (ie. 'Jesse Barnum'), rather than their shorter UID ('jbarnum').
Since users logging in typically expect to type a short name (like 'jbarnum', rather than 'Jesse Barnum'), I'd like for my DN to use my short name, like this: "CN=jbarnum,cn=users,dc=360works,dc=com". Doesn't it seem like that should be the default behavior (Windows Server 2012)?
So my question is: Can I change how the DN is constructed in Active Directory to use the short name instead of the full name?
You can change that behaviour but why should you? As you want to create a login there are much more elegant and more flexible solutions available.
When creating an LDAP based login I'm always doing the following:
bind to the server with a special account that can search the LDAP. Often that can also be done with a so called "anonymous bind".
search the LDAP for the given username in any attribute you like. A filter of (|(uid=username)(mail=username)(cn=username)) would allow your user to either use the uid, mail or cn to log in.
get the dn from the retrieved result and use that DN whic should be the DN of the users record) for a second bind - this time with the provided Password
That way the DN is completely irrellevant for your login as i is retrieved using the provided information based on attributes.
For an example in PHP have a look at https://gist.github.com/heiglandreas/5689592
The CN can be based on anything, really. It comes down to how you provision your users in the directory. If you use the out-of-box AD Users and Computers or AD Administrative Center tools to create users, they default to the full name format. You can change the CN after the fact, or if you are using something programmatic to create users, then you can create them however you like initially.