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
[PATCHES] SSH: sss_ssh_knownhostsproxy fixes
by Jan Cholasta
Hi,
the attached patches fix issues in sss_ssh_knownhostsproxy:
[PATCH 1/2] SSH: Supress error message output in sss_ssh_knownhostsproxy
[PATCH 2/2] SSH: Don't abort connection in sss_ssh_knownhostsproxy when
DNS records are missing
https://fedorahosted.org/sssd/ticket/1356
The second patch should go into both master and sssd-1-8. I'm not sure
about the first one, though.
Honza
--
Jan Cholasta
11 years, 11 months
[PATCHES] Improvements to SSSDConfig build and install
by Stephen Gallagher
Patch 0001: Make SSSDConfig a package
We were polluting the primary Python space with several
dependencies. We will now install them their own directory/module. This
has been done in such a way that existing scripts that import SSSDConfig
will require no modifications.
Patch 0002: Make default config and schema file locations configurable
Previously, we were hard-coding the sssd.conf and sssd.api.* locations
into the source. With this patch, we will take the default locations
from values specified by autoconf.
Fixes https://fedorahosted.org/sssd/ticket/1008
11 years, 11 months
[PATCHES] Support for ghost users
by Jan Zelený
Hi,
I'm sending a patch set that removes support for fake user entries and add
ghost attribute instead:
#117:
Trivial patch that only adds the SYSDB_GHOST attribute
#118:
This is one of core patches which changes the behavior on LDAP provider when
querying for groups. Instead of creating fake user entries, it uses ghost hash
table for RFC230bis and SYSDB_GHOST attribute for RFC2307.
#119:
Couple of relatively small changes to adapt proxy provider to the change. I
haven't actually tested this but the code seems straightforward to me.
#120:
Modifications in sysdb:
- removed sysdb_add_fake_user()
- modified sysdb_add_user() to remove ghost entries for the user that is
currently added.
#121:
Memberof plugin modifications: the memberof plugin does all the work when it
comes to populating memberuid.
#122:
Include ghost members as well as memberuid members in results. Alternatively
this could be solved in memberof plugin but that would lead to duplicated
information - ghost attribute would be copied to memberuid. This approach
seems better to me.
#123:
This function is no longer necessary since fake user entries don't exist any
more.
#124:
sss_groupshow utility has been modified to be aware of SYSDB_GHOST
#125:
Various small changes in the code - basically nitpicking cleanup.
Thanks
Jan
11 years, 11 months
[PATCHES] Attribute exclusion in LDAP
by Jan Zelený
The first patch (#131) adds the functionality and updates all parts of code
which use it.
The second patch (#132) utilizes the exclusion when retrieving data for
initgroups.
If you have any suggestions where else to use this functionality, please let
me know, I'll be happy to create patches and test/send them.
Thanks
Jan
11 years, 11 months
Announcing SSSD 1.8.4
by Stephen Gallagher
The SSSD team is proud to announce the bugfix release of the System
Security Services Daemon version 1.8.4.
As usual, the source can be downloaded from
https://fedorahosted.org/sssd/
== Highlights ==
Fix a bug causing AD servers not to fail over properly when the KDC
on the primary server is down
Fix an endianness bug on big-endian systems when looking up services
Fix a segfault dealing with nested groups
Make the nowait cache updates work for netgroups
Fix a regression that broke domains with
use_fully_qualified_names = True
== Tickets Fixed ==
https://fedorahosted.org/sssd/ticket/1206
RHEL5 detection in sssd.spec.in does not work
https://fedorahosted.org/sssd/ticket/1321
Warning in debug log about nscd
https://fedorahosted.org/sssd/ticket/1322
Special-case LDAP_SIZELIMIT_EXCEEDED when handling ldap return codes
https://fedorahosted.org/sssd/ticket/1324
LDAP provider needs to use all available servers for GSSAPI if the
child times out
https://fedorahosted.org/sssd/ticket/1325
heimdal: configure: Kerberos locator plugin cannot be build
https://fedorahosted.org/sssd/ticket/1329
Group enumeration fails in proxy provider
https://fedorahosted.org/sssd/ticket/1333
Potential NULL dereference in proxy provider
https://fedorahosted.org/sssd/ticket/1335
sss_groupadd no longer detects duplicate GID numbers
https://fedorahosted.org/sssd/ticket/1338
sssd does not provide maps for automounter when custom schema is
being used
https://fedorahosted.org/sssd/ticket/1340
SSSD netgroups do not honor entry_cache_nowait_percentage
https://fedorahosted.org/sssd/ticket/1343
sssd_be crashed with SIGSEGV in _tevent_schedule_immediate()
https://fedorahosted.org/sssd/ticket/1344
Loading of selinux user maps broken
https://fedorahosted.org/sssd/ticket/1348
Service lookups by port number doesn't work on s390x/ppc64 arches
== Detailed Changelog ==
Ariel Barria (2):
Potential NULL dereference in proxy provider
Warn to syslog when dereference requests fail
Jakub Hrozek (11):
Special-case LDAP_SIZELIMIT_EXCEEDED
Kerberos locator: Include the correct krb5.h header file
krb5 locator: Do not leak addrinfo
Try all KDCs when getting TGT for LDAP
Send the correct enumeration request
SYSDB: Handle user and group renames better
Use the sysdb attribute name, not LDAP attribute name
LDAP nested groups: Do not process callback with _post deep in the
nested structure
Use sized_string correctly in FQDN domains
Send 16bit protocol numbers from the sss_client
Revert the client packet length, too, after reverting the packet
protocol
Jan Engelhardt (1):
build: resolve link failure
Jan Zeleny (1):
Fixed issue in SELinux user maps
Stef Walter (3):
Limit krb5_get_init_creds_keytab() to etypes in keytab
If canon'ing principals, write ccache with updated default principal
Remove erroneous failure message in find_principal_in_keytab
Stephen Gallagher (7):
Bump version to 1.8.4
murmurhash: Relax inline requirement
RPM: Allow running 'make rpms' on RHEL 5 machines
NSS: Expire in-memory netgroup cache before the nowait timeout
KRB5: Avoid NULL-dereference with empty keytab
NSS: Restore original protocol for getservbyport
Updating translations for 1.8.4 release
11 years, 11 months
Securing remote domains
by Edward Z. Yang
Hello all,
We're interested in using SSSD to replace our current use of
NSS/PAM/NSCD/NSLCD. However, we were curious whether or not
SSSD had implemented some critical security checks to protect
against malicious remote domains.
- What are the semantics of the local domain: that is,
do I have a guarantee that entries in local will never
be affected by the network?
- If the answer to the above is true, how does SSSD resolve
conflicts between two domains which have entries that claim
the same UID? I understand that the max_id/min_id functionality
is intended to address this partially, but does SSSD do any
further sanity checks, such as refusing information from
remote domains that exist in local domains?
- Additionally, users may come with groups, and it is bad if
remote domains can spoof ownership in local groups. Is there
anyway to lock this down?
- It is frequently useful for applications running on the system
to be able to identify nonlocal users as opposed to local users;
we had a nsswitch module which identified nonlocal users and
added them to their own group. Does this functionality exist
in SSSD? (It's also convenient to have another group which contains
local users.)
- A nice to have feature (though not strictly necessary), is the
ability to pretend that nonlocal users are in some local group.
This may be necessary if remote domains cannot dictate ownership
in local groups.
In general, we would like to avoid trusting the source of the remote
authentication data: local accounts are first class, whereas remote accounts
are merely "nice to have". The remote LDAP server may not be held to as high
security standards as the machine itself, and if we can achieve isolation at
very little cost, we should do so.
The MIT Debathena and Scripts projects would be very interested
in seeing this functionality exist, and if it doesn't, we'd be
interested in contributing this functionality. We consider this
a blocker for moving to SSSD.
Thanks,
Edward
11 years, 11 months
ldap_access_filter being ignored?
by Fairlight
Hello,
I've set up OpenLDAP with PAM. Problem is, I needed name differentiation,
which sssd offers.
I've since migrated one of the two servers (I'm using replication) to
authenticate PAM using sssd.
I -can- log in just fine. One problem: the ldap_access_filter is being
ignored. I set it up to filter only to members of a certain group, and
it's just plain letting anyone log in if they're a user and have the
correct password for the account.
I've implemented memberOf as an overlay on the master and shadow LDAP
servers. I've even just totally purged and rebuilt the LDAP database from
original sources, based on something I read that said that if you implement
memberOf, it won't retroactively affect old accounts and groups. Still no
good.
I am -beyond- frustrated with this, and need it to work. I'm working with
an OpenSuSE 11.4 box, but I took out their old 1.4 version of sssd and put
in the latest 1.8.3 yesterday. So I'm working with the latest production
release.
One of the things that bothers me most is that the filter is present, but
even though it should be failing, it is letting anyone in. That makes no
sense to me. It looks like sssd was meant to err on the side of caution,
not permissiveness. That's why I don't understand why it's letting in just
anyone it finds, even if the filter fails. I even tried writing a
completely ridiculous filter that should never ever work (non-existant
group)...the users can still log in.
Any help I can get at this point would be hugely appreciated. Let me know
what you might need in terms of seeing configuration. I'll include the
relevant sssd section here [for confidentiality purposes, I changed my
client's domain name to my domain name, but everything else is accurate]:
[domain/fairlite.com]
access_provider = ldap
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldap://oh11.fairlite.com
ldap_search_base = dc=fairlite,dc=com
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/oh11.fairlite.com-CA.crt
cache_credentials = false
enumerate = true
ldap_access_filter = memberOf=cn=oh11,ou=Group,dc=fairlite,dc=com
ldap_access_order = filter
It's worth noting that I can't get memberOf to actually supply a memberuid
field with ldapsearch. That said, even if memberOf is -totally- broken,
I'd expect sssd to fail -all- logins, not let everyone in.
Any help I can get...I'd be extremely grateful for it. I really need
sssd's name differentiation. That's critical, and why I'm going with sssd
over direct ldap in the first place.
mark->
--
Fairlight-> ||| "My classmates would copulate with | Fairlight Consulting
__/\__ ||| anything that moved, but I never | http://www.fairlite.com
<__<>__> ||| saw any reason to limit myself." - | fairlite(a)fairlite.com
\/ ||| -Emo Phillips | (502) 509-3840
11 years, 11 months
