On 1/28/22 4:33 PM, NATHAN TRUHAN wrote:
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 objectclass
LDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 ms
LDAP: LdapQueryForEntries() *QUERY* number of entries returned: 1
LDAP: LdapQueryForEntries: *QUERY* base: cn=test user, ou=migrated,
ou=us, dc=company, dc=com, scope: 0, filter: , attribute: uid CN
objectclass
LDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 ms
LDAP: LdapQueryForEntries() *QUERY* number of entries returned: 1
LDAP: LdapQueryForEntries: *QUERY* base: dc=company, dc=com, scope: 2,
filter: (cn=test user), attribute: description objectclass
LDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 ms
LDAP: LdapQueryForEntries() *QUERY* number of entries returned: 1
GetParents from plugin for secLDAP:cn=test user, ou=migrated, ou=us,
dc=company, dc=com
LDAP: LdapQueryForAttribute: *QUERY* base: dc=com, scope: 0, filter:
(objectclass=*), attribute: dn
LDAP: LdapQueryForAttribute: *QUERY* result: 32 took 0 ms
LDAP: LdapQueryForAttribute: *QUERY* base: dc=company, dc=com, scope:
0, filter: (objectclass=*), attribute: dn
LDAP: LdapQueryForAttribute: *QUERY* result: 0 took 0 ms
LDAP: LdapQueryForEntries: *QUERY* base: dc=company, dc=com, scope: 2,
filter: (&(objectclass=inetOrgPerson)(cn=test user)), attribute: dn
objectclass
LDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 ms
LDAP: LdapQueryForEntries() *QUERY* number of entries returned: 1
LDAP: 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: dn
LDAP: LdapQueryForEntries: *QUERY* result: 0 took 0 ms
LDAP: LdapQueryForEntries() *QUERY* number of entries returned: 0
Failed 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=com
changetype: modify
add: aci
aci: (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.
Sorry
access control rules do not impact the connection/operation that
way. It only affects what can be modified/retrieved from the database.
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(a)lists.fedoraproject.org
To unsubscribe send an email to389-users-leave(a)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.fe...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
--
Directory Server Development Team