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'
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:
 1334089314.82847: Selected etype info: etype aes256-cts, salt
"AD.THEWALTER.LANhoststef-desktop.ad.thewalter.lan", params ""
 1334089314.100867: Retrieving STEF-DESKTOP$(a)AD.THEWALTER.LAN from
FILE:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result:
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
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  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:
> * 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.
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
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 module for PAM (Pluggable
>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.
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
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.
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?
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):
users desktop_admin_r ccache pulse-access
$ getent group | grep mock
$ getent group | grep 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
# base <dc=endoframe,dc=net> (default) with scope subtree
# filter: objectClass=posixGroup
# requesting: ALL
# users, Groups, endoframe.net
# ccache, Groups, endoframe.net
# desktop_admin_r, Groups, endoframe.net
# desktop_user_r, Groups, endoframe.net
# mock, Groups, endoframe.net
# search result
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
Can anyone shed some light on what might be happening here?
Braden McDaniel <braden(a)endoframe.com>
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!
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
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.