So... this question is maybe not solely a programming question but I hope one of you can shed some light on my issue:
The base need we have in our software is to query the groups a user is associated too with
LDAP. For this task we actually use parts of LDAP Admin to query the user. Actually we want to query for the UserPrincipalName which at least to my knowledge is the most common way right?
So.. our problem is that the AD is setup such that the user has an UPN like foo#HUS
but the user actually is bound to the domain HUS.adomain.com (aka LDAP base: dc=HUS,dc=adomain,dc=com) and searching using an UPN like foo#HUS.adomain.com does not work - only foo#HUS works. So... the question is:
Is this common?
And is there a name/resource for that?
(sorry I'm quite new to that all...)
The goal would be to use as less parameters in the administration tool as possible
aka only the base (and form from the base the UPN username).
Update: I found at least one resource (in German) that states that this is possible but not recommended by Microsoft for Azure AD. (aka having a different mail address than UPN )
When you initiate a LDAP search using a UPN like foo#HUS.adomain.com it wont work because this value is not present in the userPrincipalName value. When you search for a user by building its UPN using all the domain suffix available in the forest, then you would not consider searching the userPrincipalName attribute.
It is very difficult to build every constructed attribute from base for querying because every Active directory environment would be different. As you have mentioned that you would like to build the attribute from base, it may work if this is the only AD infra that you are targeting. Every AD infra would have its own ways in which it will be setup.
However if you would want your tool to work in any AD environment you would have to consider some other parameters.
UPN is a editable attribute . An organization can set it up or can create a user without a UPN value. Below is example of user created programmatically by using old ADSI libraries. You can repro the same by removing any users userprincipalName attribute value and the user logon account name as shown in the pictures below.
UPN is an optional attribute and a user account can be present in AD without it as well. Coming back to your specific environment in this environment only foo#HUS works because "HUS" might be setup as a valid domain suffix within the Active directory. You can check this by opening the domain.msc console on any domain controller or a machine with Remote Server Administration Tools installed. You would find the UPN suffix as shown below . I changed it in my environment as shown below.
The value you will add will now show up in the . If you remove HUS from here for example any existing user who have user#HUS userPrincipalName populated will get removed because this is a optional constructed attribute in AD. And you will have to setup this for all the users in the environment . For example check below after I changed the username to dh # HUS .
The userprincipalName value also got populated with the same.
Hope this helps clarify your query and understand more on how to use the native Active directory tools to understand more while you develop your custom LDAP search functionality/tool.
Related
For a client, we have to connect a WSO2IS 5.10.0 to an Active Directory.
For that we have created a secondary user Store with this configuration:
User store main configuration
User store optional configuration
User store advanced configuration
WSO2IS can connect to Active Directory as we can retrieve users and roles.
Before doing any claim mapping we have tried to edit and create user without any problems.
And then we have mapped some claims to retrieve more information from Active Directory.
And here come our problems:
We can't create a user in Active Directory
We can't update a user in Active Directory
This two problem gives us this error :
Caused by: javax.naming.directory.NoSuchAttributeException: [LDAP: error code 16 - 00000057: LdapErr: DSID-0C090C45,
comment: Error in attribute conversion operation, data 0, v1db1
Things that we have tried:
Check (and check a second and third time) that all our claims are mapped correctly (and they are)
Reset all claims to default mapping (on the state where we where able to create/update user)
Set User DN Pattern (as explained here)
Restart on a fresh instance of WSO2IS 5.10.0
But all things that we have tried are not helping and we are stuck.
Any help would be hugely appreciated. Thank you for any suggestions.
As asked, this is the AD attribut we have mapped :
sn
givenName
cn
displayName
name
description
mail
sAMAccountName
userPrincipalName
accountExpires
pwdLastSet
userAccountControl
scriptPath
homePhone
mobile
facsimileTelephoneNumber
title
department
company
Here the issue is LDAP_NO_SUCH_ATTRIBUTE returned from the AD.
We don't know which attribute is missing on AD side.
From the existing DEBUG logs of the server, probably you wouldn't be able to log all the attributes that WSO2 is going to update. Therefore, you have to choose an alternative option.
Manual check - Even though there are only few attributes configured (and verified) by you, there are other claims with default attribute mappings. Please check all the mapped attributes that are there in the http://wso2.org/claim dialect.
Remote debug - Remote DEBUG the server to check what are the attributes WSO2 is trying to write in to. (Smaller subset than previous approach) Then verify if those exist.
To do this remote debugging you can check out the Kernel source code from here.
To find out the correct tag to checkout, you can find the kernel version of your identity server version from this release matrix.
Once you clone and checkout the correct tag, you can use IntelliJ Idea or a capable IDE to remote debug the server as explained in the this blog.
Though it's hard to point an exact line of code, you can put DEBUG points to ActiveDirectoryUserStoreManager.doAddUser() and ActiveDirectoryUserStoreManager.doSetUserClaimValue() methods and start from there.
P.S. You can also check if the carbon log's stack trace contains any clue of the failing attribute or the respective claim, so that you can check validate it.
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.
We have an application where we store users login name in the format domain\username. We authenticate via windows and then get additional info from our database by matching the domain\username we get from the user to our database.
Now they want to move to the cloud. We authenticate users via apps in Azure AD. However, the user identifier we get back is first.last#domain.com.
I have fiddled around with https://graph.microsoft.com/v1.0/users/email and the select command to try and get the 'old' name. Howev,er I have not yet found out how to get it.
The reason they move to the cloud is that they are merging two ADs. So some users will be DomainA and some DomainB, but in the same tenant. So my first thought was to try and convert the mail to the other format. However, the two different ADs have different naming standards. One has DOMAINA\fila (two first letters from the first name and two first letters from the last name) and the other one has DOMAINB\firlas. Also it feels really ugly to try and solve it that way.
Is it possible to fetch the users loginname formatted as domain\username via Microsoft Graph?
Using the beta edition of Graph, you can obtain the user's domain and username from the onPremisesDomainName and onPremisesSamAccountName properties:
/beta/users?$select=userPrincipalName,onPremisesDomainName,onPremisesSamAccountName
The domain is stored as a FQDN so you'll need to do some translation. For example, domainName.ad.contoso.com might translate to domainName\).
This will give you a workaround so you can match up users with your internal databases. It is however only a temporary solution. Long-term, you really want to migrate to using the userPrincipalName. This is the primary user identifier and guaranteed to be unique within a given tenant.
Azure AD is a little different than the legacy Active Directory. Certain concepts from legacy AD such as Organizational Units (OUs), Group Policy Objects (GPOs), Kerberos Authentication, Lightweight Directory Access Protocol (LDAP), Domain trusts between multiple domains, and several others simply do not exist in the cloud.
[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.
I am trying to add a user to Active Directory through an MPS Web Service. I've been trying a long time to find the correct LDAP-url to use to tell it to add the new user to the Users group. I've tried things like:
LDAP://XXXX.YYY/OU=Users,DC=XXXX,DC=YYY
LDAP://XXXX.YYY/CN=Users,DC=XXXX,DC=YYY
LDAP://XXXX.YYY/DN=Users,DC=XXXX,DC=YYY
It seems the "farthest" I've gotten is an error that says I have given it an invalid Customer.
I really don't have a lot of experience with LDAP (pretty much none at all), so even just a good LDAP and Active Directory tutorial would be extremely useful (even that is eluding me right now). Thanks!
I've since lookup up the actual distinguished name in ADSI Edit, which was LDAP://XXXX.YYY/CN=Users,DC=XXXX,DC=YYY, but still have no luck.
You have error in your LDAP string.
Let's have examle:
user with account name User1 in organization unit Office1 where contoso.com is domain.
Object:
contoso.com/Users/Office1/User1
LDAP Path is:
LDAP://CN=User1,OU=Office1,OU=Users,DC=contoso,DC=com
Note that there is no slash in path itself
CN = Common Name
OU = Organizational Unit
DC = Domain Component
You can start with:
LDAP Query Basics
Creating a list of Users and their e-mail addresses in Exchange 2000
How Can I Get a List of All the Users Whose Passwords Never Expire?
if your domain is xxxx.yyyy.zzzz and you are search for all users; your path is:
LDAP://CN=Users,DC=xxxx,DC=yyyy,DC=zzzz
means every dot in domain replace with dc=
More directly, the default Users container (not a group) in a default Active Directory install would be CN=Users,dc=domain,dc=com
You are not clear if you are having trouble adding a user to a group, or if you are having trouble creating a user in a specific location.