sssd-devel May 2012

sssd-devel@lists.fedorahosted.org

25 participants
89 discussions

Start a nNew thread

[PATCH] 1213-Warn to syslog when dereference requests fail
by Ariel Barria 22 May '12

22 May '12

https://fedorahosted.org/sssd/ticket/1213

4 7

Use keytab to select etypes for krb5_get_init_creds_keytab()
by Stef Walter 22 May '12

22 May '12

It seems that when using krb5_get_init_creds_keytab(), if we don't have a keytab entry with a key using the first valid etype offered by the server, then the authentication fails. For example the keytab created by samba using 'net ads keytab create' contains: 3 STEF-DESKTOP$(a)AD.THEWALTER.LAN (des-cbc-crc) 3 STEF-DESKTOP$(a)AD.THEWALTER.LAN (des-cbc-md5) 3 STEF-DESKTOP$(a)AD.THEWALTER.LAN (arcfour-hmac) With the above file, the following appears in the KRB5_TRACE logs: [9108] 1334089314.82847: Selected etype info: etype aes256-cts, salt "AD.THEWALTER.LANhoststef-desktop.ad.thewalter.lan", params "" [9108] 1334089314.100867: Retrieving STEF-DESKTOP$(a)AD.THEWALTER.LAN from FILE:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: -1765328203/No As you'll note kerberos selected the aes256-cts enctype as that was the first one offered by the server. However our keytab didn't contain that enctype. MIT krb5 1.11 will fix also fix this issue. A patch I submitted is now in krb5 git master. Stephen suggested that sssd also fix this issue in sssd. Attached is a patch which fixes the problem in sssd as well. It doesn't fix the problem as elegantly krb5 can. For example the krb5 patch doesn't result in reordering of etypes. Additionally I'm not sure there's an easy way to detect (besides the krb5 version number) which krb5 libraries contain the fix. I've fixed several issues during preliminary review [1] of the patch, with these exceptions: > * You're returning type krb5_error_code, but you also return ENOMEM in one > place. Please replace this with an appropriate krb5_error_code value. krb5_error_code values can contain errno values. It is routine throughout the krb5 code base to return ENOMEM as a krb5_error_code. Just one example of many: https://github.com/krb5/krb5-anonsvn/blob/master/src/lib/krb5/ccache/cc_mem… > * Please open an RFE against Kerberos to export the internal function to > identify which enctypes are stronger. If the point is to fix this in sssd for use with prior versions of krb5 libraries, then this doesn't make sense. A krb5 library with this newly exported function would also contains the correct fix for the keytab etypes issue, making the attached patch irrelevant. BTW, for reasons which I don't yet understand, sssd fails when doing an ldap_sasl_initialize_s using GSSAPI on krb5 1.10.2, connecting to an AD server, with a samba keytab. It works against krb5 from git master (ie: 1.11). I guess I can debug this further when I have time. Anyway for all of the above reasons, I'm not particularly attached to this patch. But posting it here for what it's worth. Cheers, Stef [1] https://bugzilla.redhat.com/show_bug.cgi?id=811375

3 7

[PATCH] KRB5: Avoid NULL-dereference with empty keytab
by Stephen Gallagher 22 May '12

22 May '12

Fixes https://fedorahosted.org/sssd/ticket/1330 Both places in the code that consume this function are properly checking for n_etype_list > 0 before using it.

2 2

[PATCH] Simple implementation of Netscape password warning expiration control
by Stephen Gallagher 22 May '12

22 May '12

Joshua Roys submitted a patch in https://bugzilla.redhat.com/show_bug.cgi?id=726456 to add support for the Netscape password warning expiration control. I've made some modifications to his original patch to clean it up, so now I'm sending it to the list for further code-review. Fixes https://fedorahosted.org/sssd/ticket/984

2 4

Request for community input: Support of RADIUS authentication via SSSD
by Dmitri Pal 22 May '12

22 May '12

Hello, As SSSD (the System Security Services Daemon) is gaining ground as a bridge between applications running on a machine and central authentication sources such as Active Directory and FreeIPA, questions about support for other authentication protocols start to come up. One such protocol is RADIUS (Remote Authentication Dial In User Service). RADIUS is a popular authentication protocol for enterprise deployments, notably for VPN (virtual private network) and WPA (WiFI Protected Access) access. Some enterprise deployments today also rely on RADIUS for the authentication of system users. This is most often accomplished through the use of the pam_radius_auth[1] module for PAM (Pluggable Authentication Modules). >From a design standpoint, a RADIUS authentication module would be a simple fit. SSSD would acquire user identities from an LDAP directory server, but would perform authentication against a RADIUS server, rather than via LDAP simple-bind or Kerberos TGT acquisition. From a completeness perspective, it seems sensible for SSSD to implement a RADIUS authentication provider. The question we need to ask is whether support of RADIUS in SSSD adds any additional benefits. For this, we need to reach out to our community for their experience and advice. Do you have (or know of) any specific use-cases where the availability of a RADIUS authentication provider would be beneficial? Similarly, do you feel that implementation of such a provider would be best served by SSSD (and by extension, with offline cached-credentials capability), or should we recommend continued use of pam_radius_auth and simply ensure that SSSD gets out of its way? Please provide as much justification and reasoning to back your recommendations, so we can use this information to best identify our path forward on this. [1] http://freeradius.org/pam_radius_auth/ -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

1 0

everything is illuminated
by Angel Bosch 21 May '12

21 May '12

hi, as I've got all my problems resolved and this list is mainly for developers I'm going to unsubscribe. but before that I want to thanks you all for your kindly support. I'm planning a windows-linux migration in my work place and offline credentials was a stopper for me. pls, keep with this great project. abosch

2 1

sssd & AD frequently disconnecting
by Ondrej Valousek 21 May '12

21 May '12

Hi List, I am using sssd (F17) with AD and what I observed is that sssd frequently marks my AD server working and then "not working". Symptoms: (Mon May 21 13:58:43 2012) [sssd[be[default]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Mon May 21 13:58:43 2012) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Mon May 21 13:58:43 2012) [sssd[be[default]]] [get_server_status] (0x1000): Status of server 'dcpra1.XXX' is 'working' (Mon May 21 13:58:43 2012) [sssd[be[default]]] [get_port_status] (0x1000): Port status of port 389 for server 'dcpra1.XXX' is 'not working' (Mon May 21 13:58:43 2012) [sssd[be[default]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP' Sometimes sssd does manage to connect, sometimes not. I know there is a problem with the AD controller cutting the connection after some timeout that we can not (yet) handle correctly, but this also happens shortly after sssd restart. Is there any explanation to this? Thanks, Ondrej

2 2

Cached user info?
by Braden McDaniel 18 May '12

18 May '12

I'll start out by saying that I don't know if sssd is the culprit in my problem or not; but if not, I hope someone here with more knowledge of the moving parts at play can point me in the right direction. I have two machines: one with Fedora 16 and one with the Fedora 17 prerelease. I had initially created a posixGroup in LDAP for mock with GID 990. But then I realized that my two installations had different GIDs for the mock group. So, I decided to change the GID in LDAP and on the Fedora 16 box to match the GID for mock on the Fedora 17 installation (989). The Fedora 16 box seems to be just fine. However, the Fedora 17 box still seems to think that my user is a member of the group with GID 990 (which happens to be pulse-access): $ groups users desktop_admin_r ccache pulse-access $ getent group | grep mock mock:x:989: $ getent group | grep 990 pulse-access:x:990: At this point, *there is no group in LDAP with GID 990*: $ ldapsearch -x -H ldap://ldap.endoframe.net -D "cn=Manager,dc=endoframe,dc=net" -W "objectClass=posixGroup" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=endoframe,dc=net> (default) with scope subtree # filter: objectClass=posixGroup # requesting: ALL # # users, Groups, endoframe.net dn: cn=users,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup cn: users gidNumber: 100 memberUid: braden # ccache, Groups, endoframe.net dn: cn=ccache,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup cn: ccache gidNumber: 988 memberUid: braden # desktop_admin_r, Groups, endoframe.net dn: cn=desktop_admin_r,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup gidNumber: 497 cn: desktop_admin_r memberUid: braden # desktop_user_r, Groups, endoframe.net dn: cn=desktop_user_r,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup gidNumber: 496 cn: desktop_user_r # mock, Groups, endoframe.net dn: cn=mock,ou=Groups,dc=endoframe,dc=net objectClass: top objectClass: posixGroup cn: mock gidNumber: 989 memberUid: braden # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5 And here's the really goofy bit (from my perspective): if I remove braden from the LDAP mock group, "groups" output no longer lists "pulse-access"; if I add braden back to the LDAP mock group, "groups" lists "pulse-access" once again. It seems (to me) like something has cached the association of the LDAP mock group with GID 990; and now the group *name* is being got from LDAP, associated with the old GID, and that old GID is being conveyed to tools that (rightfully) associate GID 990 with the local pulse-access group. Can anyone shed some light on what might be happening here? -- Braden McDaniel <braden(a)endoframe.com>

3 12

Developer Tutorials
by Stephen Gallagher 17 May '12

17 May '12

In the interests of helping new developers get up to speed faster, I've created a new wiki page for development tutorials. So far it includes links to Pavel Březina's excellent Talloc tutorial and a few guides for git usage with the SSSD. All contributions to this effort are welcome and encouraged! https://fedorahosted.org/sssd/wiki/DevelTutorials

1 0

[PATCH] Use the sysdb attribute name, not LDAP attribute name
by Jakub Hrozek 16 May '12

16 May '12

I found two other places where we used the map name instead of sys_name. The first is the probable reason of https://fedorahosted.org/sssd/ticket/1338, although I haven't heard back from Ondrej yet if it fixed his issue completely. After I found the first one, I grepped for all occurences of "].name" and I have found the second one. As far as I can tell, we're using the maps correctly now.

2 2

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel May 2012