The bounty expires in 16 hours. Answers to this question are eligible for a +200 reputation bounty.
Aron wants to draw more attention to this question.
I am trying to query from winbindd all the AD groups a user is in.
I've tried using wbcLookupSids() to look up the user's Group Sids.
However when using wbcLookupSids() on the groups that the user is a member of, I only get the group's own Sid.
Do I HAVE to use LDAP to recursively find my user's groups?
Related
I am trying to map an AD Group I have into Keycloak, which I think I have done at least mostly correctly like so:
My issue is that, when I do this then sync then go look at the members of my group in keycloak, I see one more 'John Smith' user that is not supposed to be there (one is in my AD group, the other is not).
While the users share similar/identical English names and are both in my org's overall LDAP user federation, certainly I have confirmed that they have different email addresses and different 'Windows 2000' user IDs. Thus I am a bit lost as to why the extra John Smith is showing up in the keycloak group.
Admittedly I probably don't fully understand the nuances of all the fields in this configuration :).
UPDATE 4/8/22, from #Hamza Tahiri 's comment:
I am trying to sync my LDAP users to my keycloak users (specifically only those in one AD group)
I see several 'John Smiths' in my organization's LDAP but only one of them is in my AD Group. My issue is that TWO of these John Smith's are showing up in my keycloak group when I map it in from the AD group, vs just the one I as seen in my AD group
the full DN's of the users: I'm inferring this is the same as the LDAP_ENTRY_DN that I see in their attributes in keycloak? Let me know ifi should look somewhere else, but at least this field is DIFFERENT between the two John Smiths. The pattern of difference is as follows (triple-letters are obfuscated place-holders):
CN=John Smith,OU=AAA,OU=BBB,DC=XXX,DC=YYY,DC=ZZZ
CN=John Smith,OU=CCC,OU=BBB,DC=XXX,DC=YYY,DC=ZZZ
the LDAP_ID attributes in keycloak are also DIFFERENT between the users
The group filtering is not done correctly, or indeed the two users are members of the same groups, a workaround would be to change to search base(ldaps-groups-dn) to: OU=AAA,OU=BBB,DC=XXX,DC=YYY,DC=ZZZ.
The connecter you configured will map distant groups (AD groups), to keycloak groups, for users already imported or linked in keycloak, if this is really what you wanted in teh first place, then we can safely assume the the filtering is not working, what i would try to resolve the issue:
1 - Do an ldap search using the same value in the connector, something like:
ldapsearch -x -b <search_base> -H <ldap_host> -D <bind_dn> -W "objectclass=groups" -s sub "(&(objectclass=groups)(uid=john))"
The objective is to see if all the data you entered indeed will show the target groups.
2 - For some uknown reasons i did have some issues with the search mode parameter in keycloak, feel free to change it and see if the r chaesultsnge.
Hope this helps, feel free to update the question if you have more inputs from the differents ldapsearch you need to do in order to debug this.
Is it just me who's finding AD group is very complex? ;-(
I have a web service that only allows a certain number of role groups to have access. Say we allow people within role group 'rGroupA' to have access.
At some point, a user logs on to our web server, and we have the user name. However, we would not like to ask the user to type in the password.
Is it possible for us to know if this user belongs to 'rGroupA' somehow?
Currently, I could logon our LDAP server with my username and password and see the list of groups I am in. However, I could not search for the groups for my colleagues.
I have searched google for a while but haven't found the answer. It could be that I don't understand LDAP mechanism very well.
Many thanks!
My team just "inherited" an Archer setup with 2 ADs and LDAP sync setup for each of them. The LDAP sync works fine individually; we are able to see the users/groups as per the LDAP configuration's filters. However, we have some groups in AD#1, that contain users from AD#2 and the LDAP sync is only showing/pulling users from 1 AD in Archer. I'm on Archer 6.4.
My question:
Is it possible at all in Archer to get the groups to show members from the 2 AD's?
Does the LDAP service account need any special permissions?
Anything else that I'm missing, or any viable workarounds?
I have looked at this question which talks about some possibilities but it's quite old so starting a new question. Any help is greatly appreciated.
The question you referenced is related to Archer v5.x and v6.x, so everything I mentioned there is still valid as of 2019-04-26.
Back to the questions you asked:
Is it possible at all in Archer to get the groups to show members from the 2 AD's?
The answer is "Yes", but not that simple.
If you check tables on the back end you can see that there are two type of groups:
Manually created groups by Archer admins. These groups are not part of any LDAP source and you can't synch these groups/users.
Groups created via LDAP Synch. These groups and users are synched with LDAP Synch configuration.
In your case, if you have two LDAP synchs configured then you will have two sets of LDAP groups and two sets of LDAP users, assuming LDAP synch is configured to add and synch groups and users using filters correctly.
Based on what you shared if you have group "ABC" in both LDAP sources you will have two groups added to Archer. On the back end in the table tblGroup they will have different "ldap_config_id" values, but same name.
Same applies for users - if you have user "User1" in both LDAP sources you will end up with two users with different domains and different "ldap_config_id".
Back to your question - Yes, if you have two LDAP sources with same group name you will end up with two groups with same name, each group should have users from corresponding LDAP assigned, if you configured both LDAP synchs to add and synch groups and users.
If this doesn't work this way for you, then review your LDAP synch configuration. Your may not have an option enabled to synch groups or don't have any filters in place to get them.
Does the LDAP service account need any special permissions?
In Archer - no, but in LDAP source (Active Directory) the account you specified in LDAP configuration should have access to query certain areas. The account you use for 2nd LDAP may not have access to query groups. I'm not an expert in AD security, you should talk to AD admin on this matter.
Anything else that I'm missing, or any viable workarounds?
See the old question/answer you referenced. LDAP synch principals in Archer v5 and v6 are the same as I know.
Best solution in my opinion is to establish "virtual link" or trust between both Active Directories. Third AD can be created with both AD#1 and AD#2 merged or linked. This way you can query AD#3 and have groups and users provided for you by using only one LDAP synch configuration/Domain. This is the simplest solution for you, but your AD admin will have to do some work.
You can check other options in the old question as well.
P.S: the instance I develop for had 2 LDAP sources, but I configured them to have unique group names and unique users. This way collisions don't occur.
Good luck!
Hahn, I'm uncertain how Archer handles users from two different AD's that members in the same group found in the first AD.
It's best to reach out to Archer support and pose the question to them.
I'm also seen a simlar question in RSA Partner Community. Support may respond to that post then here or other clients that have had the same issue.
We need to now how we can check whether an account in AD has permissions to add/remove membership on AD group. AD team will be giving our service account permissions for 1000 groups at one time and we want to know a way to check quickly if we really do have permissions before confirming. Any help would be appreciated!
This is hard to answer except for the fact that when they give you permission you can test adding and removing a test user to a group. But this will all depend on the fact if the groups have all the standard default permissions when created, also the method that the AD team will give you access. Adding you to a built in group that has permission to edit the AD group, or if they are going to create a new group and add that to the AD groups. Sorry to be vague but a lot of variable here.
I have a Debian Squeeze system which is using libnss-ldap to bind to a 2008 Active Directory domain controller to look up users and groups. Everything works fine, except for some reason anyone who is in the Domain Admins, Enterprise Admins, or Schema Admins group does not get the correct group memberships. They get only the *Admin group, and no others (unless there are local groups that apply, which do show).
Stranger yet, a "getent group" shows all the correct group memberships for the user, but an "id " or "groups" (when running as the user) doesn't. We use a domain group for sudo access, and this user is unable to use sudo because it fails to see the group membership. As soon as the *Admin membership is removed, lookups work correctly.
I suspected maybe this was an AD security feature, but we have FreeBSD systems using nss-ldap on which these users' group memberships resolve correctly. There is nothing in the logs to indicate why these lookups don't return the normal results, and I haven't been able to find anything via Google to help shed light on the situation. Is anyone else using libnss-ldap in Debian to connect to an AD who can try to confirm this behavior?
Edit: I have confirmed using ldapsearch that the AD is returning the correct results. I also stopped nscd to make sure it wasn't interfering. Any user in Domain Admins sees only his primary group, local groups, and Domain Admins.
BTW, I think this is the issue:
http://support.microsoft.com/kb/976063
I have had this problem also.
I found it eventually about 18 months ago. It is a security feature of Microsoft. There is a service that runs once per hour and removes the admins from the LDAP search. If you do a query as anonymous, you will receive the correct answer for 1 hour. After one hour you will receive nothing. If you log in as a domain user, you will receive the correct information. That is why you get different results.
I do not at this point remember the service name but I am searching for it now. I found it originally on Microsoft tech net about 18 months ago, but by now, I don't remember it.
The point was that the only answer to it is
Disable that service and it does many other security items so that is not a good idea.
Change the LDAP searches to run under a domain user's log in (we have done that on some users)
Create a bogus duplicate contact with the same information for each of our admins. This is probably the easiest and quickest, but the most prone to developing wrong information over time.
The rational of this security feature is to hide all domain admins from random anonymous searches so their credentials can't be compromised by an encyclopedia password attack.
Calvin Thomas
My answer was deleted, but the problem was, in fact UAC as described in http://support.microsoft.com/kb/976063. The issue is that Domain Admins, when UAC is enabled on the DC, actually exist in two states. One that is a member of the domain admins group (i.e., the UAC 'shadow' user) and another that is the normal user. It appears that the DC only returns the former when queried with LDAP. By creating a new group, making that group a member of Domain Admins instead of the accounts themselves, and putting the accounts in the new group, the problem was resolved.