Two factor auth using SSSD
by Erinn Looney-Triggs
I have for a while had an interest in integrating Google's two factor
auth (https://code.google.com/p/google-authenticator/) into my
environment. However, the code Google gives is close but not there for a
centralized auth setup.
Now there are other projects to deal with this like totp-cgi
(https://github.com/mricon/totp-cgi) which relies on another PAM module
(pam_url).
However, it seems to me that SSSD might be an appropriate place for
something like this, so I wanted to gather some thoughts on the
feasibility of integrating two factor auth into SSSD.
Let me lay out my idea here, and open it up to criticism.
Essentially Google authenticator uses a shared secret that is held both
on the authenticating system and on the device (your cell phone). This
shared secret then has a bit of magic run on it
(https://tools.ietf.org/html/rfc6238) and if what the user enters and
what is computed match, you are good to go.
It seems to me that it would be very easy to centrally store this shared
secret (as well as some emergency codes that are generated in case you
lose your phone) in LDAP then retrieve it using SSSD (thus allowing
offline caching). The problem is that the shared secret is, well plain
text, and sensitive, I don't know if there are ways to mitigate this or
not. Is there a secure storage for something like this?
Second question is, would SSSD be an appropriate use of this, and if so,
is it easy to work into the PAM stack to have this as a second prompt, e.g.
Password:
TOTP:
Let me know your thoughts, concerns, etc.
-Erinn
11 years, 10 months
[PATCH] Try all KDCs when getting TGT for LDAP (a sssd-1.5 backport)
by Jakub Hrozek
Attached are patches that backport the fix for #1324 to the sssd-1.5
branch.
Patches 1-4 are a dependency - I needed to backport the feature to only
resolve a single service once (upstream #1214). The fix for #1324 depends
on it both contextually and also users who are hit by #1324 will most
likely be hit by #1214, too.
11 years, 10 months
sssd 1.8.4 on Debian -- fails with "ldap_result error: [Success]"
by Mantas M.
I'm trying to configure sssd 1.8.4 on a Debian Sid server to use a
LDAP+Kerberos domain, and I'm getting this error in sssd debug log:
> [sdap_process_result] (0x0040): ldap_result error: [Success]
More context:
> [sssd[be[nullroute]]] [set_server_common_status] (0x0100): Marking server 'radian.cluenet.org' as 'name resolved'
> [sssd[be[nullroute]]] [be_resolve_server_done] (0x1000): Saving the first resolved server
> [sssd[be[nullroute]]] [be_resolve_server_done] (0x0200): Found address for server radian.cluenet.org: [70.85.16.91] TTL 10467
> [sssd[be[nullroute]]] [sdap_uri_callback] (0x0400): Constructed uri 'ldap://radian.cluenet.org'
> [sssd[be[nullroute]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting
> [sssd[be[nullroute]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://radian.cluenet.org:389/??base] with fd [19].
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][].
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN]
> [sssd[be[nullroute]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
> [sssd[be[nullroute]]] [sdap_get_server_opts_from_rootdse] (0x0200): No known USN scheme is supported by this server!
> [sssd[be[nullroute]]] [sdap_get_server_opts_from_rootdse] (0x0200): Will use modification timestamp as usn!
> [sssd[be[nullroute]]] [simple_bind_send] (0x0100): Executing simple bind as: (null)
> [sssd[be[nullroute]]] [sdap_process_result] (0x0040): ldap_result error: [Success]
> [sssd[be[nullroute]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'radian.cluenet.org' as 'not working'
> [sssd[be[nullroute]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
> [sssd[be[nullroute]]] [get_server_status] (0x1000): Status of server 'radian.cluenet.org' is 'name resolved'
> [sssd[be[nullroute]]] [get_port_status] (0x1000): Port status of port 389 for server 'radian.cluenet.org' is 'not working'
> [sssd[be[nullroute]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP'
> [sssd[be[nullroute]]] [be_resolve_server_done] (0x1000): Server resolution failed: 5
> [sssd[be[nullroute]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error])
In other words, it seems to be able to connect, but considers "Success"
to be an error...
The configuration for the domain is simple, and works on Arch Linux:
> [domain/nullroute]
> enumerate = false
> dns_discovery_domain = nullroute.eu.org
> id_provider = ldap
> auth_provider = krb5
> ldap_uri = _srv_, ldap://radian.cluenet.org
> ldap_search_base = dc=nullroute,dc=eu,dc=org
> krb5_realm = NULLROUTE.EU.ORG
I'd appreciate any help.
--
Mantas Mikulėnas
11 years, 10 months
