On Mon, Feb 17, 2014 at 01:18:36AM +0000, Nordgren, Bryce L -FS wrote:
> > 1] I note that the group query includes
> (&(gidNumber=*)(!(gidNumber=0))). How do I turn that off? It will never
> find any groups that way.
> > 2] Could sssd be silently failing to produce a user entry for me
> > because some attributes are missing in AD? I did turn id_mapping on,
> > so I'd hope that make uidNumber and gidNumber optional. (see snippet
> > below:)
> > ldap_id_mapping = true
> Ah, I know what's going on...it's a bug that was fixed in master
> but not yet released in a tarball. We are finishing with the 1.11.5 release,
> though, it should be out this week.
> What I would suggest, though (and what I should have probably suggested
> from the start) would be using the AD backend:
> The AD backend is not hit by this bug.
> It should work more or less with the defaults, see the sssd-ad man page, but
> if you had to fine-tune the LDAP parameters (like the ones you used below),
> that would work, too, as the AD provider is a wrapper around the LDAP
> provider and uses much of the same code.
> > ldap_idmap_range_min = 20000
> > ldap_idmap_range_max = 1999999
> > ldap_idmap_range_size = 20000
Back at this again, after a respite. As a reminder, I'm attempting to
setup a Fedora 19 virtual machine to authenticate against our organization's
active directory, just as a user, not as admin of any kind. Just trying to
leverage it as a user store, not do SSO or anything fancy. I tried the above
(id_provider=ad with all of my ldap customizations) and sssd just would
not start. (There was a "Failed to connect to monitor services" message
in the log.) Change it back to id_provider=ldap and it started just fine
I think this is because the keytab is missing. I think we should do a
better job reporting the reason for the failure.
So then I decided to bite the bullet and try joining my little VM to
the domain. The idea here was to just let realmd set sssd up for me. No
go. This peon has no permissions to create a computer account.
Yes, unfortunately you need an account with privileges to join the
domain in order to use realmd.
So, being able to leverage AD's KDC and LDAP interfaces without joining
the domain becomes a top priority. Before I spend much more time trying
to get id_provider=ad going, does it make the assumption that the machine
is joined to the domain?
The AD provider is more or less a wrapper around LDAP and Kerberos back
ends with defaults tailored for AD and leveraging some AD-specific
features. The only 'assumption' it makes is the presence of a keytab to
use GSSAPI for authenticated searches. However, the keytab doesn't have
to be retrieved from the Linux machine itself, the AD admin could also
create it on the Windows side and transfer the keytab to the Linux box.
Alternatively, what is the progress on release
1.11.5 w/fixed id mapping for the ldap provider?
The release is in progress, I expect the tarball to be released during
today. But please note that AD doesn't allow unauthenticated connections
anyway. You'll have to either use a keytab as described above or use
bind DN and bind password using ldap_default_bind_dn and
ldap_default_authtok. Or ask your AD administrator to allow anonymous
binds on the AD side, which is not the default.
Just out of curiousity, under what circumstances does sssd use the
host/computer account credentials? Is there a way to substitute my user
credentials for host credentials? Can I use ktutil to add an entry to
/etc/krb5.keytab for my own user principal, then instruct sssd to use that
somehow? I'd really like to keep my password out of the sssd.conf file.
Yes, use can specify the principal you'd like to use with
ldap_sasl_authid. If ldap_sasl_authid is not specified, sssd would try
to find the principal in the keytab in any of the most commonly used
forms (host$@realm, host/hostname@realm, ...)