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..

On Thu, Sep 01, 2016 at 10:13:01AM +0100, John Hodrien wrote:

On Mon, 29 Aug 2016, Jakub Hrozek wrote:

...

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..

Although without a system keytab (typically the machine credential), you can't validate that you're talking to the correct KDC, can you?

correct

On Wed, Aug 31, 2016 at 04:36:58AM -0000, Daniel Hermans wrote:

Thanks Jakub,

I added as you suggested and can login! Thanks so much! Couldn't find this option in man pages etc..what does this magic flag do exactly?

Ooops, I'm sorry, this is a manpage bug. I will fix the man pages.. (I'm not sure if it makes sense to document the option in full or just document that this needs to be set for id mapping with LDAP..)

It's an attribute used purely for ID mapping with AD and normally it corresponds to https://msdn.microsoft.com/en-us/library/ms679375(v=vs.85).aspx

the primary group ( a mash of some large number with 513 on the end - Domain Users ) is coming up numeric - would you recommend a local /etc/group entry to deal with this?

Hmm, strange, this doesn't happen in my setup. If you run "sss_cache -E" and then "getent group $number", you should see SSSD converting the GID to SID and searching the SID on the AD side, does that emit some errors in the log?

On Mon, Apr 24, 2017 at 06:45:20PM -0000, maarten@datastorm.nl wrote:

Hello,

I am desperately looking for a working sssd.conf file for LDAP AD interaction. Is the working sssd.conf from Daniel Hermans somewhere to be found?

It looks like he just added: ldap_user_primary_group = primaryGroupID case_sensitive = false