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):
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
SSSD failt to start
SSSD starts and I am able to use msSFU30 attributes for things such ad GID, UID and Home dir
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 
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.
I actually have the same issue. Below is my entire sssd.conf file. Any assistance would be great! Thanks!
services = nss,pam,ssh,autofs
config_file_version = 2
domains = 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
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
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.
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..
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.
@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!
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.
rpm -qa | grep sssd
(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  domains for ID-mapping
[sdap_idmap_add_domain] (0x0020): Could not add domain [CORP.VMWARE.LOCAL] to the map: 
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] 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.
(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.
(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.
-> 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...
Do you have the same problem as John Baird described in Comment 8 ?
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.
I am pretty sure it will help; this is a reason why it is written in manual pages (@see Comment 10)
Kindly reopen the bug if you believe removing the cache didn't fix your problem.
We are experiencing same bug and removing the cache doesn't fix the problem.
(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.