Apologies for the newbie question, fairly new to LDAP and UnboundID.
I currently have an UnboundID filter that synchronises users who belong to an Active Directory group.
--set include-base-dn:cn=Users,dc=testdomain,dc=net --add "include-filter:(memberOf=CN=Application Access,CN=Users,DC=testdomain,DC=net)
The behaviour I am seeing is that when I add a user to the group "Application Access", no Synchronisation occurs.
However if I edit the users AD profile whilst they are a memberOf "Application Access" then the user profile is synchronised.
Is is possible to synchronise users when they join a group?
Thanks in advance.
In Microsoft Active Directory the MemberOf value is the DN of an entry that the current entry is a member in a Group and is referred to as a Forward Reference.
A Pseudo Attribute Microsoft Active Directory
MemberOf is a Pseudo Attribute. This implies You can not monitor the MemberOf attribute for changes (Like with DirXML)
Within Microsoft Active Directory MemberOf is flagged as "NO-USER-MODIFICATION" (or System-Only)[1]; This means you can NOT update the attribute. In order to add a user to a group you have to write the user's dn to the member attribute on the group object.
-jim
Related
Why a normal domain user on a domain joined Computer can see all users and groups on the domain through win32_account Class? Can this be prevented?
This is by Msft default design. "Authenticated Users" are allowed to read Azure AD objects (in general, some specific attributes excepted).
You can change this in AD object rights, but Msft is usually not recommending this, at least for the domain root. You may try it with the object properties of a Ou and move users below this.
You can edit these rights in "ActiveDirectory Users and Computers":
right click OU
select "Properties"
select Tab "Security"
remove "Read" from "Authenticated Users"
Or
create a User Group for selected users you want to prevent from browsing
add this group to Security and add "Deny" for "Read"
I've been looking for a way to identify a user in Active Directory without fail. I found this article which explains which fields are unique. It's a good starting point, but doesn't identify which fields are non-mutable. Further google queries result in AzureAD results on immutableId, which is what I want, but for regular AD. The case I'm trying to prevent is I use sAMAccountName (which is unique) to identify a user, but an admin decides to change the sAMAccountName for some reason (perhaps for uniformity) and I identify the same old user (with now a new sAMAccountName as a new user.
A few contenders from the article:
DN
UPN
sAMAccountName
ObjectGUID
Is there anything I'm missing? Is there an immutableId equivalent in pure AD (Not AzureAD)?
What you likely want is objectGUID. As "GUID" suggests, it is "globally unique". It doesn't change, even when the account is moved to another domain.
There is also objectSid (SID = Security Identifier), which is what Windows permissions use (the SID is stored in the permissions). It is also globally unique, but part of the SID is the SID of the domain. So if the account is moved to another AD domain, a new SID is generated on that domain, and the old objectSid is put in the sIDHistory of the new account.
There is some extra reading about that here: Security identifiers and globally unique identifiers
The distinguishedName changes whenever the account is renamed or moved to a new OU.
As you noted, both userPrincipalName and sAMAccountName can change too.
I'm trying to set up an external active directory GAL on zimbra 8.8.7; My current working filter is
(&(|(displayName=*%s*)(cn=*%s*)(sn=*%s*)(givenName=*%s*)(mail=*%s*))(|(&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact))(objectCategory=publicFolder)(objectCategory=msExchDynamicDistributionList)))
autocomplete filter is
(|(cn=%s*)(sn=%s*)(gn=%s*)(mail=%s*))
LDAP search base
dc=sub,dc=domain,dc=com
search and autocomplete returns all AD users, including admin accounts. What is a correct way to exclude administrators group from ldap search?
the accounts I need to exclude are in OU "Admins" and are members of couple of groups like Buildin "Administrators" and users "Domain Admins", "Enterprise admins", etc
I've tried adding (&(objectCategory=group)(!cn=Admin) but it doesn't seem to be valid.
Decided to post my workaround that is already in production. Couldn't make exclusion rule to work and another task required the real employees group to be created on AD anyway, so ended up adding all people accounts to group Staff and domain GAL search looks like this:
LDAP filter: (&(objectCategory=Person)(sAMAccountName=*)(memberOf=cn=Staff,ou=Groups,dc=dc1,dc=domainname,dc=com))
Autocomplete filter: (|(cn=%s*)(sn=%s*)(gn=%s*)(mail=%s*))
LDAP search base: dc=dc1,dc=domainname,dc=com
I have made an application, where I want to bring all the user accounts and their memberships in the Active Directory Environment. I came to know that a user in Active Directory has memberOf attribute which stores the distinguishedName of the groups of which a user is a member.
However, when I checked out and found the memberOf isn't all the groups of which user is a member of. For example, it only contains few distinguishedName of the groups in other domain of same forest.
Am I missing something ? Is there some configuration which has to be done on Active Directory.
Please note, I am using Java JNDI for bringing the users form the active directory.
I'm currently working on an application which uses LDAP as an authentication method. I was wondering if the LDAP protocol has a standard membership attribute which would hold the user's group? So far memberOf is working in OpenLDAP and Active Direcotry but not in Apache DS. I couldn't find this attribute in the RFCs so I'm kind of confused. Should I be using the memberOf attribute or I need to go the old fashion way traversing over all of the groups to find which group has the member?
By the standards, only the member attribute on the group (as used by Microsoft Active Directory) can be "counted" on.
RFC 4519 section 2.17 states:
"The 'member' attribute type contains the distinguished names of objects that are on a list or in a group. Each name is one value of this multi-valued attribute."
The memberOF (used by Microsoft Active Directory) and groupMberShip (used by eDirectory) are implementation specific attribute added to the user.
The memberOF (used by Microsoft Active Directory) attribute is controlled by the server and is not modifiable. (flagged as Read Only from LDAP and System-Only in MS speak)
-jim