[Freeipa-devel] Search global catalog for trusted domain SIDs

Alexander Bokovoy abokovoy at redhat.com
Thu Oct 18 21:22:16 UTC 2012


On Thu, 18 Oct 2012, Sumit Bose wrote:
>On Thu, Oct 18, 2012 at 11:42:34PM +0300, Alexander Bokovoy wrote:
>> On Thu, 18 Oct 2012, Sumit Bose wrote:
>> >On Thu, Oct 18, 2012 at 10:00:54PM +0300, Alexander Bokovoy wrote:
>> >>Hi,
>> >>
>> >>this is work in progress, shared mostly to get comments.
>> >>
>> >>Simo, Sumit, this is an attempt to resolve external group members from
>> >>trusted domains using their Global Catalog services.
>> >>
>> >>The code quickly became complex because it needs to do a lot of
>> >>additional activity. A rough sequence is following:
>> >>1. Match external member against existing trusted domain
>> >>2. Find trusted domain's domain controller
>> >>3. Fetch trusted domain account auth info
>> >>4. Set up ccache in /tmp/krb5cc_TRUSTEDDOMAIN with principal
>> >>   ourdomain$@trusted.domain
>> >>5. Do LDAP SASL interactive bind using the ccache
>> >>6. Search for the member's SID
>> >>7. Decode SID
>> >>8. Replace an external member name by SID in the group-add-member
>> >>   command
>> >>
>> >>Right now I'm failing at SASL interactive bind as Global Catalog does
>> >>not accept the credentials in DomainValidator.__resolve_against_gc(),
>> >>perhaps because I'm using LDAP SASL interactive bind wrongly. It is late
>> >>here so I might simply be blind already.
>> >>
>> >>[Thu Oct 18 21:42:08.924696 2012] [:error] [pid 7831] [client
>> >>192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr:
>> >>DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1',
>> >>'desc': 'Invalid credentials'}
>> >>
>> >>Note that ccache is successfully created and populated and
>> >>is usable from command line via ldapsearch:
>> >>
>> >...
>> >>+
>> >>+    def __resolve_against_gc(self, info, name):
>> >>+        conn = IPAdmin(host=info['dc'], port=3268)
>> >>+        auth = self.__extract_trusted_auth(info)
>> >>+        if auth:
>> >>+            (ccache_name, principal) = self.__kinit_as_trusted_account(info, auth)
>> >>+            if ccache_name:
>> >>+                cb_info = dict()
>> >>+                (CB_USER, CB_GETREALM) = (0x4001, 0x4008)
>> >>+                cb_info[CB_USER] = principal
>> >>+                cb_info[CB_GETREALM] = info['dns_domain'].upper()
>> >>+                sasl_auth = _ldap.sasl.sasl(cb_info,'GSSAPI')
>> >>+                old_ccache = os.environ.get('KRB5CCNAME')
>> >>+                os.environ["KRB5CCNAME"] = ccache_name
>> >>+                conn.sasl_interactive_bind_s(None, sasl_auth)
>> >>+                os.environ["KRB5CCNAME"] = old_ccache
>> >
>> >Are you sure the bind is already finished here? I haven't looked at the
>> >implementation, but if it does a lazy bind, i.e. only bind when the
>> >first request is made, it will see the wrong  ccache. Can you try to
>> >set KRB5CCNAME to the old value after calling conn.getEntry()?
>> Yes, I'm sure because it raises exception from within
>> sasl_interactive_bind_s() call, it never ever gets to the next line.
>>
>> [Thu Oct 18 23:28:12.421356 2012] [:error] [pid 8183] [client 192.168.111.206:0]     conn.sasl_interactive_bind_s(None, sasl_auth)
>> [Thu Oct 18 23:28:12.421412 2012] [:error] [pid 8183] [client 192.168.111.206:0]   File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 556, in sasl_interactive_bind_s
>> [Thu Oct 18 23:28:12.421832 2012] [:error] [pid 8183] [client 192.168.111.206:0]     return self.conn.sasl_interactive_bind_s(who, auth, serverctrls, clientctrls, sasl_flags)
>> [Thu Oct 18 23:28:12.421854 2012] [:error] [pid 8183] [client 192.168.111.206:0]   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
>> sasl_interactive_bind_s
>> [Thu Oct 18 23:28:12.422086 2012] [:error] [pid 8183] [client 192.168.111.206:0]     return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
>> [Thu Oct 18 23:28:12.422108 2012] [:error] [pid 8183] [client 192.168.111.206:0]   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call
>> [Thu Oct 18 23:28:12.422134 2012] [:error] [pid 8183] [client 192.168.111.206:0]     result = func(*args,**kwargs)
>> [Thu Oct 18 23:28:12.422196 2012] [:error] [pid 8183] [client 192.168.111.206:0] INVALID_CREDENTIALS: {'info': '8009030B: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 0, v1db1', 'desc': 'Invalid credentials'}
>>
>
>ok another guess. In the python docs it is said the "Such changes to the
>environment affect subprocesses started with os.system(), popen() or
>fork() and execv()." So I guess os.environ["KRB5CCNAME"]=something does
>not change the environment of the running process, but only python data.
>If I try to set a new env var in the python interpreter and look at
>/proc/PID/environ from a different shell, I see no changes.
No, this does not matter. I'm reproducing the same error with a
standalone app that does not modify environment:
http://cpaste.org/1370/raw/

We do modify environment in the framework code (ipaserver/rpcserver.py)
already and it works just fine.

-- 
/ Alexander Bokovoy




More information about the Freeipa-devel mailing list