On 1/28/22 4:33 PM, NATHAN TRUHAN wrote:
Sorry access control rules do not impact the connection/operation that way. It only affects what can be modified/retrieved from the database.Hello,Sorry for the long post:
I have an Oracle Linux 7.9 installation running 389 Directory Server 1.3.It contains 3 suffixes. The first is the o=netscaperoot. The second is the Administration Domain based on the FQN of the server: dc=prodapps, dc=prodvcn, dc=oraclevcn, dc=com. The third is one that was manually created to store users and groups from an AD migration which I will refer to as dc=company,dc=com. Under this third suffix, I created 2 OUs to match what I was retrieving out of AD, ou=MIGRATED, ou=US.
I created a user under the dc=company,dc=com called lsc. So its DN is uid=lsc,dc=company,dc=com. This user has full control over the suffix in that it can query, create, and remove objects, it is used with the lsc-project tools to migrate and transform the AD content, which was brought over successfully.
I am accessing this from SAP BusinessObjects also remapping from AD to LDAP. And you specify a specific Bind DN and Base DN to utilize and that is what it should use to query from.
However, what I see in the Ldap Query behavior from the application is this:LDAP: LdapQueryForEntries: *QUERY* base: dc=company, dc=com, scope: 2, filter: (uid=Test.User), attribute: dn objectclassLDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 msLDAP: LdapQueryForEntries() *QUERY* number of entries returned: 1LDAP: LdapQueryForEntries: *QUERY* base: cn=test user, ou=migrated, ou=us, dc=company, dc=com, scope: 0, filter: , attribute: uid CN objectclassLDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 msLDAP: LdapQueryForEntries() *QUERY* number of entries returned: 1LDAP: LdapQueryForEntries: *QUERY* base: dc=company, dc=com, scope: 2, filter: (cn=test user), attribute: description objectclassLDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 msLDAP: LdapQueryForEntries() *QUERY* number of entries returned: 1GetParents from plugin for secLDAP:cn=test user, ou=migrated, ou=us, dc=company, dc=comLDAP: LdapQueryForAttribute: *QUERY* base: dc=com, scope: 0, filter: (objectclass=*), attribute: dnLDAP: LdapQueryForAttribute: *QUERY* result: 32 took 0 msLDAP: LdapQueryForAttribute: *QUERY* base: dc=company, dc=com, scope: 0, filter: (objectclass=*), attribute: dnLDAP: LdapQueryForAttribute: *QUERY* result: 0 took 0 msLDAP: LdapQueryForEntries: *QUERY* base: dc=company, dc=com, scope: 2, filter: (&(objectclass=inetOrgPerson)(cn=test user)), attribute: dn objectclassLDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 msLDAP: LdapQueryForEntries() *QUERY* number of entries returned: 1LDAP: LdapQueryForEntries: *QUERY* base: dc=prodapps, dc=prodvcn, dc=oraclevcn, dc=com, scope: 2, filter: (&(objectclass=groupOfNames)(member=cn=test user, ou=migrated, ou=us, dc=company, dc=com)), attribute: dnLDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 msLDAP: LdapQueryForEntries() *QUERY* number of entries returned: 0Failed to add alias 'Test.User'. Reason: It is not a member in any of the mapped groups.Error encountered on Object (9388): Creation of the user Test.User cannot complete because the user is not a member in any of the mapped groups.
In the above case, I am trying to add the user test.user (which is cn=test user,ou=migrated,ou=us,dc=company,dc=com) and has a uid of test.user. The system finds that without an issue.
However, the next part, I don't know how or why the bind user uid=lsc is then changing the base dn to the Administration Domain and attempting the search there for a group member. This base dn should have remained dc=company, dc=com.
To get around this, I am trying to block access to the Administration Domain suffix for the lsc user. I removed anonymous bind access, then added this aci:dn: dc=prodapps,dc=prodvcn,dc=oraclevcn,dc=comchangetype: modifyadd: aciaci: (target="ldap:///dc=prodapps,dc=prodvcn,dc=oraclevcn,dc=com")(version 3.0; acl "Deny company dc user access to prodapps";deny(all) userdn="ldap:///uid=*,dc=company,dc=com || ldap:///cn=*,dc=company,dc=com";)
After this, when using tools such as Apache Directory Studio, the lsc user didn't see the Admin Domain if it went to retrieve the available DNs. However, a ldapsearch still worked, it did a bind properly, just returned no records like expected:ldapsearch -x -LLL -h server -p 389 -D "uid=lsc,dc=company,dc=com" -b "dc=prodapps, dc=prodvcn, dc=oraclevcn, dc=com" -W "(&(objectclass=groupOfNames)(member=cn=test user, ou=migrated, ou=us, dc=company, dc=com))"
Is there any way I can block a dn completely so it would fail to connect to the search not just return 0 records? This way the application wouldn't be able to retrieve it and move on to another DN.
Or what would be the detriment of 389 DS running with just the one Suffix that is both the Administration Domain as well as the one used for migration (which occurs only under the ou)? i.e. re-creating the Administration Domain as dc=company,dc=com instead of the FQM domain of dc=prodapps,dc=prodvcn,dc=oraclevcn,dc=com.
It is better to run with one suffix when possible. The less backends the better. You'll need o=netscaperoot for the Java console though (unless you are not using the java console then you can remove this suffix). The only issue with changing your "suffix" is that you need to update your configurations (replication, client configs, and adm.conf(?)) to use the new suffix.
HTH,
Mark
Thanks in advance, and sorry for the long post.Nathan
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Directory Server Development Team
No comments:
Post a Comment