Bug 1116758

Summary: ldap_id_mapping = False causes SSSD service startup failure
Product: [Fedora] Fedora Reporter: Chris Cowley <chris>
Component: sssdAssignee: Jakub Hrozek <jhrozek>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: abokovoy, chris, iain.t.morris, jhrozek, john.w.baird, lslebodn, pbrezina, preichl, sbose, sgallagh, ssorce, viggiani
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-10 08:30:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Centos 6 SSSD.CONF
none
SSSD Debug Domain Log none

Description Chris Cowley 2014-07-07 09:02:13 UTC
Description of problem:
When setting the above attribute in order to use POSIX attributes from Active Directory, disabling ldap_id_mapping causes SSSD startup to fail


Version-Release number of selected component (if applicable):
sssd-1.11.6-1.fc20.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Add the line `ldam_id_mapping = False` to `/etc/sssd/sssd.conf` in the relevant domain section
2. restart sssd service
3.

Actual results:
SSSD failt to start

Expected results:
SSSD starts and I am able to use msSFU30 attributes for things such ad GID, UID and Home dir

Additional info:
In the logs I see:

```
==> /var/log/sssd/sssd_domain.local.log <==
(Mon Jul  7 10:32:29 2014) [sssd[be[domain.local]]] [load_backend_module] (0x0010): Error (5) in module (ad) initialization (sssm_ad_id_init)!
(Mon Jul  7 10:32:29 2014) [sssd[be[domain.local]]] [be_process_init] (0x0010): fatal error initializing data providers
(Mon Jul  7 10:32:29 2014) [sssd[be[domain.local]]] [main] (0x0010): Could not initialize backend [5]
```

Comment 1 Lukas Slebodnik 2014-07-07 09:16:06 UTC
Could you upload your sssd.conf? You can make attachment private.

You can also try to add "debug_level = 9" into AD domain section and you should see more verbose debug messages in sssd log files.

Comment 2 John Baird 2014-08-05 14:56:52 UTC
I actually have the same issue.  Below is my entire sssd.conf file.  Any assistance would be great!  Thanks!

#####
[sssd]
services = nss,pam,ssh,autofs
config_file_version = 2
domains = CORP.VMWARE.LOCAL

[domain/CORP.VMWARE.LOCAL]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

ad_server = dc01.corp.vmware.local
ad_hostname = ipa01.corp.vmware.local
ad_domain = corp.vmware.local

ldap_id_mapping = False
ldap_schema = ad
cache_credentials = true
ldap_disable_referrals = true

debug_level = 9

[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
######

Comment 3 John Baird 2014-08-05 15:40:28 UTC
Created attachment 924249 [details]
Centos 6 SSSD.CONF

I just wanted to actually attach my sssd.conf file as requested.  Also, I have compiled the sssd-1.11.6 RPM for Centos 6 from source and I have the same issue that is seen in the FC20 RPM.

Comment 4 Jakub Hrozek 2014-08-06 07:29:19 UTC
Can you also attach the logs we requested with debug_level=9 The config file looks good to me and I was able to run sssd just fine with a similar one..

Comment 5 John Baird 2014-08-06 12:50:42 UTC
Created attachment 924473 [details]
SSSD Debug Domain Log

Added debug_level = 9 to start up.  Nuked logs prior to service start attempt so everything in the log is directly from the failed start attempt.  No other files had any logging associated with them.

Comment 6 John Baird 2014-08-12 17:54:13 UTC
@jakub, have you been able to take a look at this?  I am hoping to test a 1.10 release of sssd to see if that cleans it up.  I will let you know what I find.  Thanks for your help!

Comment 7 Iain Morris 2014-08-12 20:20:36 UTC
I don't have much more to add but to say this is happening to me on a CentOS 7 system attaching to an AD domain with Identity Management for Unix extensions.  Almost identical sssd.conf config to the users above.  Switching to ldap_id_mapping = True removes the problem and all AD users are available, but using AD sid mapping rather than POSIX.

Relevant versions:
rpm -qa | grep sssd
sssd-ipa-1.11.2-68.el7_0.5.x86_64
sssd-client-1.11.2-68.el7_0.5.x86_64
sssd-proxy-1.11.2-68.el7_0.5.x86_64
sssd-common-pac-1.11.2-68.el7_0.5.x86_64
sssd-krb5-1.11.2-68.el7_0.5.x86_64
python-sssdconfig-1.11.2-68.el7_0.5.noarch
sssd-krb5-common-1.11.2-68.el7_0.5.x86_64
sssd-ldap-1.11.2-68.el7_0.5.x86_64
sssd-1.11.2-68.el7_0.5.x86_64
sssd-common-1.11.2-68.el7_0.5.x86_64
sssd-ad-1.11.2-68.el7_0.5.x86_64

Comment 8 Lukas Slebodnik 2014-08-22 21:34:58 UTC
(In reply to John Baird from comment #5)
> Created attachment 924473 [details]
> SSSD Debug Domain Log
> 
> Added debug_level = 9 to start up.  Nuked logs prior to service start
> attempt so everything in the log is directly from the failed start attempt. 
> No other files had any logging associated with them.

I would like to apologise for late reply.
I checked log files and this art is interesting and at least we need to improve logging

[sysdb_idmap_get_mappings] (0x4000): cn=id_mappings,cn=CORP.VMWARE.LOCAL,cn=sysdb
[sdap_idmap_init] (0x0100): Initializing [1] domains for ID-mapping
[sdap_idmap_add_domain] (0x0020): Could not add domain [CORP.VMWARE.LOCAL] to the map: [11]
    If I read source code correctly, return code 11 means:
          New domain collides with existing one

[sdap_idmap_init] (0x0020): Could not add domain [CORP.VMWARE.LOCAL][S-1-5-21-71412705-2218169384-2449183948][6147] to ID map: [Input/output error]
 


In sssd.conf, option ldap_id_mapping is disabled, but there is old idmapping range in sssd cachec.

Could you try to:
 * remove file rm -f /var/lib/sssd/db/*
 * start sssd one more time.

Comment 9 Iain Morris 2014-08-26 19:45:47 UTC
(In reply to Lukas Slebodnik from comment #8)

> In sssd.conf, option ldap_id_mapping is disabled, but there is old idmapping
> range in sssd cachec.
> 
> Could you try to:
>  * remove file rm -f /var/lib/sssd/db/*
>  * start sssd one more time.


This fixed the problem for me.  Thank you for your time on this.

Comment 10 Lukas Slebodnik 2014-08-26 21:41:08 UTC
(In reply to Iain Morris from comment #9)
> (In reply to Lukas Slebodnik from comment #8)
> 
> > In sssd.conf, option ldap_id_mapping is disabled, but there is old idmapping
> > range in sssd cachec.
> > 
> > Could you try to:
> >  * remove file rm -f /var/lib/sssd/db/*
> >  * start sssd one more time.
> 
> 
> This fixed the problem for me.  Thank you for your time on this.

BTW it is already documented in manual page.
man sssd-ldap
    -> ID MAPPING
        -> (3rd paragraph)

       Please note that changing the ID mapping related configuration options
       will cause user and group IDs to change. At the moment, SSSD does not
       support changing IDs, so the SSSD database must be removed...

Comment 11 Lukas Slebodnik 2014-08-26 21:44:22 UTC
Do you have the same problem as John Baird described in Comment 8 ?

Comment 12 Iain Morris 2014-09-02 23:14:28 UTC
I'm sorry for the late response.  I did not have the sssd debug logs turned up as high as John Baird's output so it's difficult to say if it is the same problem scanning through his attachment.  The sssd service simply wouldn't start with ldap_id_mapping enabled.  It would be interesting to know if his problem was resolved with clearing out the sssd db directories.  Thanks again.  The system is now in production so I can't change it back to troubleshoot this with you, unfortunately.

Comment 13 Lukas Slebodnik 2014-09-03 06:20:17 UTC
I am pretty sure it will help; this is a reason why it is written in manual pages (@see Comment 10)

Comment 14 Jakub Hrozek 2014-09-10 08:30:57 UTC
Kindly reopen the bug if you believe removing the cache didn't fix your problem.

Comment 15 Mimmus 2015-02-23 11:03:30 UTC
We are experiencing same bug and removing the cache doesn't fix the problem.
Any help?

Comment 16 Lukas Slebodnik 2015-02-23 12:23:31 UTC
(In reply to Mimmus from comment #15)
> We are experiencing same bug and removing the cache doesn't fix the problem.
> Any help?

In this case,  you are hitting another bug.
See comment 10.

Feel free to open another BZ with attached log files.