On Mon, 29 Oct 2012, Rob Crittenden wrote:
[Mon Oct 29 16:15:33 2012] [error] [client 192.168.122.240]   File
"/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line
562, in sasl_interactive_bind_s
[Mon Oct 29 16:15:33 2012] [error] [client 192.168.122.240]     return
self.conn.sasl_interactive_bind_s(who, auth, serverctrls, clientctrls,
sasl_flags)
[Mon Oct 29 16:15:33 2012] [error] [client 192.168.122.240]   File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
sasl_interactive_bind_s
[Mon Oct 29 16:15:33 2012] [error] [client 192.168.122.240]     return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)

[Mon Oct 29 16:15:33 2012] [error] [client 192.168.122.240]   File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
_ldap_call
[Mon Oct 29 16:15:33 2012] [error] [client 192.168.122.240]     result
= func(*args,**kwargs)

[Mon Oct 29 16:15:33 2012] [error] [client 192.168.122.240]
LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information
(Cannot determine realm for numeric host address)', 'desc': 'Local
error'}
Somehow name resolution failed for you -- you probably need to restart
named before it actually would start working. I had similar issues with
caching of forwarder rules.


Should we catch sasl exceptions?
Yes, we should. I'm not sure how to present them to the user, though.
Actual outcome is that we were unable to resolve the referenced external
user or group and thus would not add it to the list of external members.
I.e., command should fail but what error message should be dispalyed
since the user is anyway unable to affect the situation -- we are using
trust password to auth against GC and if that doesn't work, whole trust
does not work either.

For cases like above ('Cannot determine realm for numeric host
address'), we would need to map it to misconfiguration and explain what
to fix. This step is rather open right now, since we don't really know
why it failes (barring DNS issues).


--
/ Alexander Bokovoy

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to