ldap_autofs_search_base not domain based

Bug #1635885 reported by Fati Iseni
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
sssd (Ubuntu)
New
Medium
Unassigned

Bug Description

Hi,

The search base parameter for autofs was intented to be set for each domain separately, but it fails to do so. The value of the first occurence of the parameter somehow is set for all domain sections.

I'm posting example configuration below. There are 2 domains, and in this case the ldap_autofs_search_base parameter of the "skp.fids" domain overrides the rest of the occurencies. If you just switch the precedence in the domain defintions "fids, skp.fids", then the oposite is valid.

I have used subdomain in the example and it might be confusing, but nevertheles, I did bunch of tests including completely different domains with same results. In a contrary the sudo_search_base is working just fine.
I tried including scope as well, but it didnt help. I was tracking the ldap request on the ldap server side when autofs service is restarted. It always searches for one record, there is no additional request for the other domain (I'm posting the logs too)

Environment:
Ubuntu Server 14.04.5 LTS x86_64
SSSD 1.11.8-0ubuntu0.2

CONFIGURATION

[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, sudo, autofs
domains = skp.fids, fids

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[autofs]

[domain/skp.fids]
; Using enumerate = true leads to high load and slow response
enumerate = false
cache_credentials = false

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
autofs_provider = ldap

ldap_uri = ldap://ldap.skp.fids
ldap_search_base = dc=skp,dc=fids
ldap_sudo_search_base = ou=sudoers,dc=skp,dc=fids
ldap_autofs_search_base = ou=automount,ou=admin,dc=skp,dc=fids
ldap_tls_reqcert = never

krb5_kdcip = kerberos.skp.fids
krb5_realm = SKP.FIDS
krb5_changepw_principle = kadmin/changepw
krb5_auth_timeout = 15
krb5_renewable_lifetime = 5d

[domain/fids]
; Using enumerate = true leads to high load and slow response
enumerate = false
cache_credentials = false

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
autofs_provider = ldap

ldap_uri = ldap://ldap.skp.fids
ldap_search_base = dc=fids

ldap_uri = ldap://ldap.skp.fids
ldap_search_base = dc=fids
ldap_sudo_search_base = ou=sudoers,dc=fids
ldap_autofs_search_base = ou=automount,ou=admin,dc=fids
ldap_tls_reqcert = never

krb5_kdcip = kerberos.skp.fids
krb5_realm = FIDS
krb5_changepw_principle = kadmin/changepw
krb5_auth_timeout = 15
krb5_renewable_lifetime = 5d

LOGS (this is the only request in the logs)

...
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=1 SRCH base="ou=automount,ou=admin,dc=fids" scope=2 deref=0 filter="(&(ou=auto.master)(objectClass=automountMap))"
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=1 SRCH attr=objectClass ou
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 22 12:15:41 vav slapd[1294]: conn=1077 fd=25 ACCEPT from IP=192.168.91.101:36298 (IP=0.0.0.0:389)
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=2 SRCH base="ou=auto.master,ou=automount,ou=admin,dc=fids" scope=2 deref=0 filter="(&(cn=*)(objectClass=automount))"
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=2 SRCH attr=objectClass cn automountInformation
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=3 SRCH base="ou=automount,ou=admin,dc=fids" scope=2 deref=0 filter="(&(ou=auto.home)(objectClass=automountMap))"
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=3 SRCH attr=objectClass ou
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=4 SRCH base="ou=auto.home,ou=automount,ou=admin,dc=fids" scope=2 deref=0 filter="(&(cn=*)(objectClass=automount))"
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=4 SRCH attr=objectClass cn automountInformation
Oct 22 12:15:41 vav slapd[1294]: conn=1077 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 22 12:15:49 vav slapd[1294]: conn=1077 op=5 SRCH base="ou=sudoers,dc=fids" scope=2 deref=0
...

Fati Iseni (fatiiseni)
description: updated
Revision history for this message
Jakub Hrozek (jakub-hrozek) wrote :

I think the issue might be different, because the autofs search base is only read by the domain itself and the domains cannot affect one another. So I suspect the autofs responder is not moving to another domain once it finds the auto.master map in the first iteration.

But we need logs to see what's going on, please follow https://fedorahosted.org/sssd/wiki/Troubleshooting

Revision history for this message
Fati Iseni (fatiiseni) wrote :

Hi Jakub,

I was referring to all of the services in general, but yes you're right, more specifically, the problem may relay on autofs responder. And I should mention that it doesnt move to another domain after successful hit on the first attempt. I did some test, and put some base that doesnt contain "auto.master"; in that case it moves to another domain and that's the default one now.

I added debug_level=6 logs. I'm attaching the respective logs (I tried to extract only the important ones).

Let me know if you need anything else, or if i can be of any help.

Cheers

Revision history for this message
Fati Iseni (fatiiseni) wrote :

Domain logs added!

Robie Basak (racb)
Changed in sssd (Ubuntu):
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.