On Fri, 29 Jul 2011, Stephen Gallagher wrote:
On Fri, 2011-07-29 at 14:09 +0200, Jan Zelený wrote:
>> Jan Zelený wrote:
>>> Yes, in recent versions you should have something like
>>>
>>> libnss3.so()(64bit)
>>
>> Just to confirm, this all now works perfectly and either GSSAPI or TLS.
>> Am I right in assuming they are mutually exclusive?
>
> Yes, they should be. However I'm not entirely sure if they are made mutually
> exclusive in the code. We shall verify this.
I think we don't stop you from setting ldap_id_use_start_tls, but it's
only going to introduce unnecessary slowdown (encrypting everything
twice).
It doesn't work if I enable both. I figured it wasn't necessary anyway as
there's no need, but thought I'd mention it.
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [objectClass]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [sAMAccountName]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [userPassword]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [msSFU30UidNumber]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [primaryGroupID]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [displayName]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [msSFU30HomeDirectory]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [msSFU30LoginShell]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [userPrincipalName]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [cn]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [memberOf]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [nsUniqueId]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [modifyTimestamp]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [shadowLastChange]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [shadowMin]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [shadowMax]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [shadowWarning]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [shadowInactive]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [shadowExpire]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [shadowFlag]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [krbLastPwdChange]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [krbPasswordExpiration]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [pwdAttribute]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [authorizedService]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [accountExpires]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [userAccountControl]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (7): Requesting
attrs: [nsAccountLock]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_get_generic_step] (8):
ldap_search_ext called, msgid = 6
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_id_op_connect_done] (9): caching
successful connection after 1 notifies
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [be_run_online_cb] (3): Going online.
Running callbacks.
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace:
sh[0x2098090], connected[1], ops[0x1ff00e0], ldap[0x2096f00]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result gave
-1, something bad happend!
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_handle_release] (8): Trace:
sh[0x2098090], connected[1], ops[0x1ff00e0], ldap[0x2096f00], destructor_lock[0],
release_memory[0]
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [remove_connection_callback] (9):
Successfully removed connection callback.
(Fri Jul 29 13:57:11 2011) [sssd[be[default]]] [sdap_id_op_done] (5): communication error
on cached connection, moving to next server
John, you should be aware of
https://fedorahosted.org/sssd/ticket/783
though. Currently we don't support AD's standards-violating RANGE
extension, so we're limited to the first 1500 (AD 2008) or 1000 (AD
2003) users listed in a group.
AD standards violating? You do surprise me... ;)
To be honest it was easy enough to trip up nss_ldap and nscd with this sort of
stuff too, so it shouldn't be something we depend on.
So if you have any exceedingly large groups, you're likely to hit
this.
This is only about *flat* groups though I assume? Largest group I can find
that I use is <1500 flat members (we'll be pure 2008 by the time I use this).
I'm thinking sssd likely to crawl into a hole at some point anyway, but the
caching's a whole lot more sane, so I'm hoping it'll plod along more
successfully than nss_ldap/nscd.
jh