On Wed, May 6, 2015 at 4:27 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> You know, just this morning, I was thinking about enumeration. It
> doesn't work for IPA views at all for example. It doesn't work for
> trusted domains at all either (except for some limited support in AD
> trusted domains that is very untested)
>
> I wonder if we could just remove enumeration from IPA and AD back
> ends in some major release.
Please don't do this.
Enumeration is a very useful feature. It allows us to do things like
this:
$ getent passwd | grep -i lastname
The equivalent ldapsearch command is much more tedious:
$ ldapsearch -z 0 -E pr=2147483647/noprompt -o ldif-wrap=no -L -L -H
'ldap:///dc%3Dexample%2Cdc%3Dorg -Y GSSAPI -N -b "dc=example,dc=org"
"(&(objectClass=user)(cn=*lastname*))" dn cn sAMAccountName
More generically, enumeration is the way Unix/Linux has always worked.
Even getting users to change from:
grep -i lastname /etc/passwd
To this:
getent passwd | grep -i lastname
...has been a struggle.
We also have various services that (unfortuantely) pre-load the passwd
and group files at startup by enumerating them with getpwent_r() and
getgrent_r(), instead of using the get*nam_r() and get*id_r()
functions as-needed. These services break outright if enumeration is
disabled.
(Yes, these services are broken. Yes, they shouldn't do that. But our
ability to fix them is extremely limited at best, because we don't
control them.)
Finally, we have many systems that cannot be joined to Active
Directory (for policy reasons, not technical reasons). But we want to
use the same passwd/group entries on those systems as returned by sssd
on hosts that are joined to Active Directory. We do this by scraping
the output of "getent -s sss passwd" and "getent -s sss group" and
manually merging it into the local passwd and group files
(respectively) on these hosts.
> It's just a legacy feature, so those who need it can fall back to
> the LDAP provider..
But the LDAP provider doesn't support ID mapping; only the AD provider
does. And ID mapping is the main reason we use sssd.
I'm not asking you to make enumeration the default. It shouldn't be;
it should be something you only turn on if you need it, and you KNOW
you need it. But if you need it, you NEED it. Please don't take it
away.

Hello.
I've configured domain membership for one linux server, and now I'm
trying to understand one thing. I can't figure out how SASL-GSSAPI
encrypts LDAP requests and GC interactions. As long as I understood
Kerberos, it's a protocol solely for authentication, and SASL-GSSAPI
gives it ability to encrypt all data transactions between authenticated
hosts. But this encryption is not mandatory.
I've done several queries via 'id' utility to generate traffic, and
captured it. All I can see is LDAP traffic to 389/tcp and 3268/tcp,
which is encrypted. I can decrypt it by loading host's keytab to
Wireshark.
We've disabled anonymous and insecure binds (without integrity checking
or SSL/TLS encryption) in AD, and didn't adjust minssf/maxssf parameters
on Linux. As long as I understood, AD does not require whole session
encryption, neither does Linux.
All authentication is done in SSSD (authconfig --enablesssd
--enablesssdauth).
To summarize: I want to understand, why SASL-GSSAPI encrypts whole
connection and not just auth phase, so I could be sure that one day all
connections wouldn't appear in plaintext on the network.
If I had more experience in programming, I've could find the answer in
source code (all hail to opensource) to fullfill my curiosity, but
unfortunately I can't do that, so I'll appreciate any help/hints/links
on the topic.
Kind regards.

Hi,
(Warning: It's been a looong day, and upon rereading, the below may not be entirely coherent. I'll gladly clarify in the morning where needed)
We've been struggling for several months with getting our Linux (a mix of CentOS 7 and RHEL 7.1) servers AD integrated. We have a Win2012R2 domain with two sites, and several cross-forest, one-way trusts, and at the moment we are mostly (see below) able to authenticate with accounts local to our domain. We currently have two problems (that we know of):
* After a few days, it is no longer possible to log in with a domain account. Restarting sssd mostly works, and if not, performing a domain join again does. What we've seen is that this seems to change the KVNO field of kinit -k, and we've seen an error message (which I can't find again at the moment, sorry) indicating that this is a problem. Oddly enough, on some of the servers which we still can log on to, the KVNO can be different from the one which we just "fixed". The KVNO seems to always be either 2 or 5, switching when we "fix" a server.
* Authenticating with an account from a trusted domain never works. I can ping domain controllers from the other domain, I can telnet all the AD ports I can think of (significantly, 389 and 88), and there's no real error message shown anywhere. Right now /var/log/secure complains about unknown users, and journalctl says "Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)". I can resolve both A and PTR records, both on local and remote domains.
I'm at a loss on how to continue with the troubleshooting. People are starting to mumble about requesting local accounts on all machines. Tonight, I tried throwing PBIS Open (previously Likewise) on a machine, and it just worked. I'd like to avoid PBIS, though, since it is a bit more opaque about how it works, and we'd probably end up having to pay to get the features we could get from sssd in a (mostly) more understandable and clean packaging. But this would at least seem to indicate that the issue is with our configuration, rather than some infrastructural problem?
Here's the configuration files:
/etc/krb5.conf:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = AD.MAIN-DOMAIN.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
[domain_realm]
/etc/sssd/sssd.conf
[sssd]
services = nss, pam, ssh, autofs
config_file_version = 2
domains = AD.MAIN-DOMAIN.COM
[nss]
override_homedir = /home/%d/%u
override_shell = /bin/bash
[domain/AD.MAIN-DOMAIN.COM]
id_provider = ad
use_fully_qualified_names = TRUE
krb5_renew_interval = 1h
I tried replacing the krb5.conf file with the one generated by PBIS, but that didn't help, unfortunately.
Any ideas for things to try would be greatly appreciated!
Best regards,
Carl

Hi,
I would like to use SSSD to allow authentication on linux machines for
users managed in 2 LDAP bases.
While SSSD is capable of supporting several domains, it seems to only
allow to handle the case where uid/gid are well partitioned between the
bases, with no conflicts (each base having its own uid/gid range).
I'm wondering if there is any plan to add support in SSSD for
renumbering uid and gid in the case of bases which are not well
partitioned ?
Or if anyone already faced the problem and found a nice way to manage
such a use case ?
Thanks,
BR
--
Pierre

Hi!
We store our public ssh keys in AD user account (altSecurityIdentities).
Red Hat release 6.6/sssd 1.11.6. Adding
subdomains_provider = none
alone ends in not being able to get the public key but are asked for our
AD user accounts password.
Adding
ldap_groups_use_matching_rule_in_chain = True
ldap_initgroups_use_matching_rule_in_chain = True
makes the logon time so long that it seems that SSSD forgets the content
of the attribute altSecurityIdentities and we are asked for our AD user
accounts password. But logging on immediatly again we are asked for
public key verification.
Red Hat release 7.1/sssd 1.12.2. . Adding
subdomains_provider = none
alone ends in not being able to get the public key but are asked for our
AD user accounts password.
Adding
ldap_groups_use_matching_rule_in_chain = True
ldap_initgroups_use_matching_rule_in_chain = True
gives the same result. AD user accounts password only. But not the
extended logon time.
How come?
Regards
Davor vusir

Hello all,
First off, a big thanks to the developers for providing this piece of
software! Now, to the point!
I've recently run into the error(?) message below (/var/log/messages) on
some of our infrastructure nodes which have upgraded from sssd 1.9.x to
sssd-1.12.4-47:
sssd[be[rc.usf.edu]]: dereference processing failed : Input/output error
sssd[be[rc.usf.edu]]: dereference processing failed : Input/output error
Doing some online research and checking the list archives (2012-2015), I
found that other users with varied versions of sssd and Linux had run into
this issue as well. It was suggested that they should use
"ldap_deref_threshold = 0". A user also reported no errors after enabling
enumeration. I've done both on a test node and the message persists. I
even purged the db and cache without luck. I am using "error(?)" because I
am not experiencing any user/group resolution errors. All calls to getent
and id are successful.
A thread from February 2013 [1] had a suggestion to check LDAP with a deref
call and without. On the affected nodes, it does return a result; the OP
of that thread said that the deref call failed.
I also saw bug report for IPA 4.0 [2] that seems to reference the same
issue, but I'm not able to duplicate the problem.
There was an update to the LDAP servers via yum (minor bug fix revisions)
for 389ds and IPA, but nothing major. All other nodes running sssd-1.9.x
are not manifesting this message.
We're using FreeIPA (IPA server 3.0.0-47) with 389ds 1.2.11.15-60.
I can produce detailed logs upon request, but before doing so I was hoping
that the community could tell me if the message is a red herring and can be
safely ignored, or if there something else that should be checked. It's
just very odd that the older clients aren't manifesting the message and
these new clients are, even though nothing seems "broken".
[1]
https://lists.fedorahosted.org/pipermail/sssd-users/2013-February/000418....
[2] https://fedorahosted.org/freeipa/ticket/4389
Thanks for any information!
John DeSantis