Requiring local accounts with sssd

[tsm]

Is there an easy way to require that a local account be present using sssd? I configured it for ldap/kerberos and it works, but unfortunately it works for everyone in ldap, meaning anyone with an id can log in, which I don't want.

I could just disable sssd, but that seems like the coward's way out

[tsm]

Answered my own question.

If you change the account setting for pam_localuser to requried in /etc/pam.d/password-auth and /etc/pam.d/system-auth, that makes any login check for the user in /etc/passwd.

The odd thing is that the id command seems to be using sssd too. I can id userids that are not in /etc/passwd and they come up since they're in ldap.

I wish there was some way to isolate the id command to /etc/passwd because with sssd enabled, you can't use the commandline utilities to add users. useradd, userdel and usermod won't work because they already detect a user present.

[sgallagh]

Answered my own question.

If you change the account setting for pam_localuser to requried in /etc/pam.d/password-auth and /etc/pam.d/system-auth, that makes any login check for the user in /etc/passwd.

The odd thing is that the id command seems to be using sssd too. I can id userids that are not in /etc/passwd and they come up since they're in ldap.

I wish there was some way to isolate the id command to /etc/passwd because with sssd enabled, you can't use the commandline utilities to add users. useradd, userdel and usermod won't work because they already detect a user present.

There's a better way to restrict users. Look at the manpage for sssd-simple (the simple access-control provider). You can add a list of users to the system that are allowed access, and then only they will be able to log in.

It is intentional that 'id' and 'getent' should return information for users not local to the system. This is because if you wanted to use NFS or view files from other LDAP users, it will allow you to recognize their ownership, even if that user has never logged into the local machine.

Why do you want to user useradd, userdel or usermod on users that conflict with LDAP? That's a recipe for disaster, honestly. You never want there to be overlap, because POSIX does not have any mechanism for disambiguating them. It's a VERY GOOD THING that useradd denies you this.

--
Stephen Gallagher
Lead Developer of the System Security Services Daemon

[tsm]

Well, this is where my experience level fails me. Our servers are within a library at a large university and I only have a handful of people who need shell access, but rather than require users to manage passwords for various servers, we had kerberos configured for authentication.

Now we're migrating from Solaris to Red Hat and the authentication systems are pretty new to me. I thought I'd try to use sssd as it seems a pretty cool way to go, but I was tripped up by its integration with other systems.

It seems that sssd would work better if I had a local LDAP with all the necessary groups created, but I don't so I was using our University LDAP for testing. The upshot was that the way I had it set up, anyone on campus could log in.

Thanks for the suggestion on sssd-simple. I'll check that out. I also have kerberos working outside of sssd, so I could also re-order things in pam and turn sssd off.

[sgallagh]

Well, this is where my experience level fails me. Our servers are within a library at a large university and I only have a handful of people who need shell access, but rather than require users to manage passwords for various servers, we had kerberos configured for authentication.

Now we're migrating from Solaris to Red Hat and the authentication systems are pretty new to me. I thought I'd try to use sssd as it seems a pretty cool way to go, but I was tripped up by its integration with other systems.

It seems that sssd would work better if I had a local LDAP with all the necessary groups created, but I don't so I was using our University LDAP for testing. The upshot was that the way I had it set up, anyone on campus could log in.

Thanks for the suggestion on sssd-simple. I'll check that out. I also have kerberos working outside of sssd, so I could also re-order things in pam and turn sssd off.

Well, SSSD is primarily designed for use in centralized authentication systems. So it's expected for the most part that access-control would also be based around centrally-managed groups.

I'm not sure why you would turn SSSD off in order to use pam_krb5. You probably just want to be using auth_provider = krb5 in /etc/sssd/sssd.conf (and set krb5_kdcip = <KDC address>, and krb5_realm = <KRB5_REALM>). That will use kerberos for authentication and acquire a TGT for single-sign-on the same way that pam_krb5.so would.

The best thing you could do would be to talk to your system administrators and get them to create a group in LDAP containing your users, and use that with the simple access provider. If that's not an option, then you can always use a simple whitelist with the 'simple_allow_users' option.

If you have other questions, I encourage you to post them to to the sssd-devel mainling list. Linux Forums won't allow me to post the link, but if you Google 'sssd-devel' you should find it.