#6797 As a ID user I cannot call a command with --rights option
Closed: fixed 7 years ago Opened 7 years ago by pvomacka.

Description:
As an ID user I try to call command i.e. (ipa config-show --rights or ipa idoverrideuser-show "id view" user@DOM-AD.EXAMPLE ) and I get "ipa: ERROR: no matching entry found". So getting effective rights does not work for AD users. The problem is in CLI and also during performing API calls.

Steps to reproduce:
1. Install FreeIPA and AD server
2. Establish trust between those two machines
3. kinit as AD user or Administrator (# kinit Administrator@DOM-AD.EXAMPLE)
4. try to run any command with --rights options ($ ipa config-show --rights --all)
5. "ipa: ERROR: no matching entry found" is shown

Expected result:
Get entry with effective rights.

The following traceback is taken from /var/log/httpd/error_log, with "debug = True" set in /etc/ipa/default.conf and performing:
$ ipa idoverrideuser-show "Default Trust View" Administrator@DOM-AD.EXAMPLE --rights

0x7fde76f0ae18>
[Wed Mar 22 10:27:51.943448 2017] [wsgi:error] [pid 36695] ipa: DEBUG: WSGI wsgi_execute PublicError: Traceback (most recent call last):
[Wed Mar 22 10:27:51.943480 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 367, in wsgi_execute
[Wed Mar 22 10:27:51.943485 2017] [wsgi:error] [pid 36695]     result = command(*args, **options)
[Wed Mar 22 10:27:51.943489 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in __call__
[Wed Mar 22 10:27:51.943493 2017] [wsgi:error] [pid 36695]     return self.__do_call(*args, **options)
[Wed Mar 22 10:27:51.943504 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in __do_call
[Wed Mar 22 10:27:51.943508 2017] [wsgi:error] [pid 36695]     ret = self.run(*args, **options)
[Wed Mar 22 10:27:51.943511 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run
[Wed Mar 22 10:27:51.943515 2017] [wsgi:error] [pid 36695]     return self.execute(*args, **options)
[Wed Mar 22 10:27:51.943519 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1327, in execute
[Wed Mar 22 10:27:51.943522 2017] [wsgi:error] [pid 36695]     ldap, entry_attrs.dn)
[Wed Mar 22 10:27:51.943526 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 212, in get_effective_rights
[Wed Mar 22 10:27:51.943530 2017] [wsgi:error] [pid 36695]     rights = ldap.get_effective_rights(dn, attrs)
[Wed Mar 22 10:27:51.943533 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 291, in get_effective_rights
[Wed Mar 22 10:27:51.943537 2017] [wsgi:error] [pid 36695]     "krbPrincipalAux", base_dn=self.api.env.basedn)
[Wed Mar 22 10:27:51.943540 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1469, in find_entry_by_attr
[Wed Mar 22 10:27:51.943544 2017] [wsgi:error] [pid 36695]     base_dn, filter=filter, attrs_list=attrs_list)
[Wed Mar 22 10:27:51.943547 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1317, in get_entries
[Wed Mar 22 10:27:51.943551 2017] [wsgi:error] [pid 36695]     **kwargs)
[Wed Mar 22 10:27:51.943555 2017] [wsgi:error] [pid 36695]   File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1448, in find_entries
[Wed Mar 22 10:27:51.943558 2017] [wsgi:error] [pid 36695]     raise errors.EmptyResult(reason='no matching entry found')
[Wed Mar 22 10:27:51.943562 2017] [wsgi:error] [pid 36695] EmptyResult: no matching entry found
[Wed Mar 22 10:27:51.943565 2017] [wsgi:error] [pid 36695] 

Metadata Update from @pvomacka:
- Issue priority set to: 1

7 years ago

The problem comes from the ldap2.get_effective_rights implementation which assumes that bind principal always has 'krbprincipalname' attribute by which the framework looks up the bind DN:

    def get_effective_rights(self, dn, attrs_list):                             
        """Returns the rights the currently bound user has for the given DN.       

           Returns 2 attributes, the attributeLevelRights for the given list of 
           attributes and the entryLevelRights for the entry itself.            
        """                                                                     

        assert isinstance(dn, DN)                                               

        principal = getattr(context, 'principal')                               
        entry = self.find_entry_by_attr("krbprincipalname", principal,          
            "krbPrincipalAux", base_dn=self.api.env.basedn)                     
   <SNIP/>

This obviously does not apply for ID overriden AD users (or AD users in general). Given that we plan to support external users anyway, maybe it is a good time to supply the connection context with bind DN of the bound user along with his principal name.

The problem comes from the ldap2.get_effective_rights implementation which assumes that bind principal always has 'krbprincipalname' attribute by which the framework looks up the bind DN:

    def get_effective_rights(self, dn, attrs_list):                             
        """Returns the rights the currently bound user has for the given DN.       

           Returns 2 attributes, the attributeLevelRights for the given list of 
           attributes and the entryLevelRights for the entry itself.            
        """                                                                     

        assert isinstance(dn, DN)                                               

        principal = getattr(context, 'principal')                               
        entry = self.find_entry_by_attr("krbprincipalname", principal,          
            "krbPrincipalAux", base_dn=self.api.env.basedn)                     
   <SNIP/>

This obviously does not apply for ID overriden AD users (or AD users in general). Given that we plan to support external users anyway, maybe it is a good time to supply the connection context with bind DN of the bound user along with his principal name.

I don't think you actually need to go that deep. We are already connected to the LDAP server, so self.conn.whoami_s()[4:] is all you need to acquire DN of the bind:

diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py
index def1245..b07b708 100644
--- a/ipaserver/plugins/ldap2.py
+++ b/ipaserver/plugins/ldap2.py
@@ -286,12 +286,16 @@ class ldap2(CrudBackend, LDAPClient):

         assert isinstance(dn, DN)

-        principal = getattr(context, 'principal')
-        entry = self.find_entry_by_attr("krbprincipalname", principal,
-            "krbPrincipalAux", base_dn=self.api.env.basedn)
+        bind_dn = None
+        try:
+            bind_dn = self.conn.whoami_s()[4:]
+        finally:
+            if bind_dn is None:
+                return None
+
         sctrl = [
             GetEffectiveRightsControl(
-                True, "dn: {0}".format(entry.dn).encode('utf-8'))
+                True, "dn: {0}".format(bind_dn).encode('utf-8'))
         ]
         self.conn.set_option(_ldap.OPT_SERVER_CONTROLS, sctrl)
         try:

Metadata Update from @abbra:
- Issue assigned to abbra

7 years ago

ipa-4-5:

  • 7d48fb8 ldap2: use LDAP whoami operation to retrieve bind DN for current connection
    master:

  • 7324451 ldap2: use LDAP whoami operation to retrieve bind DN for current connection

ipa-4-5:

  • 7d48fb8 ldap2: use LDAP whoami operation to retrieve bind DN for current connection
    master:

  • 7324451 ldap2: use LDAP whoami operation to retrieve bind DN for current connection

Metadata Update from @pvoborni:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1435718

7 years ago

Metadata Update from @pvoborni:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1435718

7 years ago

Metadata Update from @mbabinsk:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

7 years ago

Metadata Update from @jcholast:
- Issue set to the milestone: FreeIPA 4.5.1

7 years ago

Login to comment on this ticket.

Metadata