Re: Trying to deny any bind/query rights to Administration Domain suffix for user

Mark Reynolds <mareynol@xxxxxxxxxx> · Fri, 28 Jan 2022 16:43:43 -0500



    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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

    
    -- 
Directory Server Development Team
  
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure