On Mon, Aug 29, 2016 at 03:36:40PM +0200, Jakub Hrozek wrote:
On Mon, Aug 29, 2016 at 09:07:06AM +0200, Jakub Hrozek wrote:
> On Sat, Aug 27, 2016 at 06:06:17AM -0000, Daniel Hermans wrote:
> > Hi,
> > i'd like to use sssd in ldap mode against Active Directory so I have
defined:
> > id_provider = ldap
> > auth_provider = ldap
> >
> > Yes krb5 would be better but i only have a BIND account and cannot add computer
objects.
> > This 'should' be possible - it works with nslcd. As I don't have
Posix attributes i'm using:
> > ldap_id_mapping = true
> > fallback_homedir = /home/%d/%u
> > default_shell = /bin/bash
> >
> > sssd can bind with LDAPS and can seem to get user info from the domain:
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_process_message] (0x4000):
Message type: [LDAP_RES_SEARCH_ENTRY]
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_parse_entry] (0x1000):
OriginalDN: [CN=Some User,OU=Admin Accounts,DC=dev,DC=somedomain,DC=com].
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_process_result] (0x2000):
Trace: sh[0x7f5d15fbc030], connected[1], ops[0x7f5d1639d140], ldap[0x7f5d15fb5cd0]
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_process_message] (0x4000):
Message type: [LDAP_RES_SEARCH_RESULT]
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_get_generic_op_finished]
(0x0400): Search result: Success(0), no errmsg set
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_op_destructor] (0x2000):
Operation 3 finished
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_search_user_process] (0x0400):
Search for users, returned 1 results.
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_search_user_process] (0x4000):
Retrieved total 1 users
> >
> > The UID mapping seems to succeed:
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [ldb] (0x4000): start ldb
transaction (nesting: 0)
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0400): Save
user
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x4000): Failed to
retrieve UUID [2][No such file or directory].
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0400): SID
S-1-5-21-3970895924-989261097-3267629119-1443 does not belong to any known domain
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_get_primary_name] (0x0400):
Processing object someuser
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0400):
Processing user someuser
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x1000): Mapping
user [someuser] objectSID [S-1-5-21-3970895924-989261097-3267629119-1443] to unix ID
> >
> > But it gets no further with this message:
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_get_idmap_primary_gid]
(0x0080): no primary group ID provided
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0020): Cannot
get the GID for [someuser] in domain [extdev].
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0020): Failed to
save user [someuser]
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_users] (0x0040): Failed
to store user 0. Ignoring.
> >
> > Have tried against two different domains with identical result ( one a cleanly
installed 2012R2 domain ).
> >
> > Any ideas what I'm doing wrong? Is this possible? Various (old) posts
suggests it is.
> >
> > This was first (incorrectly) posted to sssd-devel, Jakub Hrozek updated and
told me to define ldap_idmap_default_domain_sid so sssd no longer reports this:
> > (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0400): SID
S-1-5-21-3970895924-989261097-3267629119-1443 does not belong to any known domain
>
> Can you post your sssd.conf, please? For some reason, SSSD was unable to
> map the user's primary GID, but could map UID, which is strange. I also
> don't know why SSSD is still saying:
> (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0400): SID
S-1-5-21-3970895924-989261097-3267629119-1443 does not belong to any known domain
> when the domain SID should be assigned in the config file...
OK, I found your sssd.conf in the Red Hat support case you also filed
and found our your config is missing:
ldap_user_primary_group = primaryGroupID
in AD environment you'll also definitely want to set:
case_sensitive = false
btw one more remark. Even if you can't join the client to AD and have to
resort to id_provider=ldap there is nothing preventing you from using:
auth_provider=krb5
at least as long as the KDC is reachable..