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