On 18/09/13 07:59, Ondrej Valousek wrote:
>Hmmm,
>
>Looks like a bug in 1.10?
>My search looks different:
>(Wed Sep 18 08:47:17 2013) [sssd[be[vendavo.com]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with
[(&(nisMapName=auto.master)(objectclass=nisMap))][CN=CZ,CN=NIS,DC=vendavo,DC=com].
>
>I am using AD mapping, but it should not matter.
>Try to downgrade to 1.9.2 to see if it helps....
>
>Ondrej
>
>________________________________________
>From: sssd-users-bounces(a)lists.fedorahosted.org
[sssd-users-bounces(a)lists.fedorahosted.org] on behalf of Rowland Penny
[repenny241155(a)gmail.com]
>Sent: Tuesday, September 17, 2013 9:21 PM
>To: End-user discussions about the System Security Services Daemon
>Subject: Re: [SSSD-users] sssd, autofs and active directory
>
>On 16/09/13 17:08, Rowland Penny wrote:
>>On 16/09/13 16:53, Ondrej Valousek wrote:
>>>Strange, which version of sssd are you running? SSSD & Autofs & AD
>>>works for granted in sssd ver 1.9.2
>>>Ondrej
>>>________________________________________
>>>From: sssd-users-bounces(a)lists.fedorahosted.org
>>>[sssd-users-bounces(a)lists.fedorahosted.org] on behalf of Rowland
>>>Penny [repenny241155(a)gmail.com]
>>>Sent: Monday, September 16, 2013 5:41 PM
>>>To: End-user discussions about the System Security Services Daemon
>>>Subject: [SSSD-users] sssd, autofs and active directory
>>>
>>>Hello, I have inserted the automount schema into Samba 4 AD and got it
>>>to work (for those thinking that it will not work, try changing the two
>>>objectClasses to auxillary not structural)
>>>
>>>I can now add the following ldif to the AD database:
>>>
>>>dn: OU=automount,DC=example,DC=com
>>>objectClass: top
>>>objectClass: organizationalUnit
>>>ou: automount
>>>name: automount
>>>
>>>dn: OU=auto.master,OU=automount,DC=example,DC=com
>>>objectClass: top
>>>objectClass: automountMap
>>>objectClass: organizationalUnit
>>>ou: auto.master
>>>name: auto.master
>>>automountMapName: auto.master
>>>
>>>dn: CN=/shares,OU=auto.master,OU=automount,DC=example,DC=com
>>>objectClass: top
>>>objectClass: automount
>>>objectClass: container
>>>cn: /shares
>>>name: /shares
>>>automountKey: /shares
>>>automountInformation: auto.shares
>>>
>>>dn: OU=auto.shares,OU=automount,DC=example,DC=com
>>>objectClass: top
>>>objectClass: automountMap
>>>objectClass: organizationalUnit
>>>ou: auto.shares
>>>name: auto.shares
>>>automountMapName: auto.shares
>>>
>>>dn: CN=dropbox,OU=auto.shares,OU=automount,DC=example,DC=com
>>>objectClass: top
>>>objectClass: automount
>>>objectClass: container
>>>cn: dropbox
>>>name: dropbox
>>>automountKey: dropbox
>>>automountInformation:
>>>-fstype=cifs,rw,username=rowland,password=xxxxxxxxxx,uid=3001106,iocharset=utf8
>>>
>>>://192.168.0.2/dropbox
>>>
>>>And if I setup the client as follows:
>>>
>>>/etc/default/autofs
>>>
>>>MASTER_MAP_NAME="OU=auto.master,OU=automount,DC=example,DC=com"
>>>LOGGING="verbose"
>>>LDAP_URI="ldap://homeserver.example.com" # AD server name
>>>SEARCH_BASE="OU=automount,DC=example,DC=com"
>>>MAP_OBJECT_CLASS="automountMap"
>>>ENTRY_OBJECT_CLASS="automount"
>>>MAP_ATTRIBUTE="automountMapName"
>>>ENTRY_ATTRIBUTE="automountKey"
>>>VALUE_ATTRIBUTE="automountInformation"
>>>AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf"
>>>
>>>/etc/autofs_ldap_auth.conf
>>>
>>><?xml version="1.0" ?>
>>><!--
>>>This files contains a single entry with multiple attributes tied to it.
>>>See autofs_ldap_auth.conf(5) for more information.
>>>-->
>>>
>>><autofs_ldap_sasl_conf
>>> usetls="no"
>>> tlsrequired="no"
>>> authrequired="yes"
>>> authtype="GSSAPI"
>>> clientprinc="THINKPAD$(a)EXAMPLE.COM"
>>>/>
>>>
>>>/etc/nsswitch.conf
>>>
>>>...........
>>>automount: ldap
>>>
>>>It works! I can browse to the mount point and the share from the server
>>>is mounted.
>>>
>>>If I now modify sssd to control autofs.
>>>
>>>[sssd]
>>>config_file_version = 2
>>>domains =
example.com
>>>services = nss, pam,autofs
>>>
>>>[nss]
>>>
>>>[pam]
>>>
>>>[autofs]
>>>
>>>[domain/example.com]
>>>description = AD domain with Samba 4 server
>>>cache_credentials = true
>>>enumerate = false
>>>id_provider = ldap
>>>auth_provider = krb5
>>>chpass_provider = krb5
>>>access_provider = ldap
>>>
>>>krb5_server =
server.example.com
>>>krb5_kpasswd =
server.example.com
>>>krb5_realm =
EXAMPLE.COM
>>>
>>>ldap_referrals = false
>>>
>>>ldap_schema = rfc2307bis
>>>ldap_access_order = expire
>>>ldap_account_expire_policy = ad
>>>ldap_force_upper_case_realm = true
>>>
>>>ldap_user_object_class = user
>>>ldap_user_name = sAMAccountName
>>>ldap_user_home_directory = unixHomeDirectory
>>>ldap_user_principal = userPrincipalName
>>>
>>>ldap_group_object_class = group
>>>ldap_group_name = sAMAccountName
>>>autofs_provider = ldap
>>>
>>>ldap_sasl_mech = GSSAPI
>>>
>>>ldap_autofs_search_base = OU=automount,DC=example,DC=com
>>>
>>>ldap_autofs_map_object_class = automountMap
>>>ldap_autofs_entry_object_class = automount
>>>ldap_autofs_map_name = automountMapName
>>>ldap_autofs_entry_key = automountKey
>>>ldap_autofs_entry_value = automountInformation
>>>
>>>/etc/nsswitch.conf
>>>
>>>...........
>>>automount: sss
>>>
>>>sudo service sssd restart
>>>sudo service autofs restart
>>>
>>>autofs now no longer works. If we look in the logs we find:
>>>
>>>/var/log/syslog
>>>
>>>Sep 16 15:10:50 ThinkPad automount[4056]: Starting automounter version
>>>5.0.7, master map OU=auto.master,OU=automount,DC=example,DC=com
>>>Sep 16 15:10:50 ThinkPad automount[4056]: using kernel protocol
>>>version 5.02
>>>Sep 16 15:10:50 ThinkPad automount[4056]: setautomntent: lookup(sss):
>>>setautomntent: No such file or directory
>>>Sep 16 15:10:50 ThinkPad automount[4056]: no mounts in table
>>>
>>>/var/log/sssd/sssd_example.com.log
>>>
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>>>[(&(automountMapName=OU=auto.master,OU=automount,DC=example,DC=com)(objectclass=automountMap))][OU=automount,DC=example,DC=com].
>>>
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs:
>>>[automountMapName]
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]] [sdap_process_result]
>>>(0x2000): Trace: sh[0x7166f0], connected[1], ops[0x725020],
>>>ldap[0x6e04b0]
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no
>>>errmsg set
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[sdap_get_automntmap_process] (0x0400): Search for autofs maps, returned
>>>0 results.
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[sdap_autofs_setautomntent_done] (0x0080): Could not find automount map
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[sysdb_delete_autofsmap] (0x0400): Deleting autofs map
>>>OU=auto.master,OU=automount,DC=example,DC=com
>>>(Mon Sep 16 15:10:50 2013) [sssd[be[example.com]]]
>>>[be_autofs_handler_callback] (0x1000): Request processed. Returned
>>>0,0,Success
>>>
>>>
>>>sssd seems to be searching using this filter:
>>>(&(automountMapName=OU=auto.master,OU=automount,DC=example,DC=com)(objectclass=automountMap))][OU=automount,DC=example,DC=com].
>>>
>>>
>>>which means to me, search in the base
'OU=automount,DC=example,DC=com'
>>>for the attribute 'automountMapName' which contains
>>>'OU=auto.master,OU=automount,DC=example,DC=com' AND the DN that
contains
>>>'automountMapName' must also contain the objectClass
'automountMap'
>>>
>>>Is this correct?
>>>
>>>If I am correct, then I think that sssd is never going to work with
>>>autofs & AD as is, even though Steve assures me it does. This is
>>>because, even though the DN
>>>'OU=auto.master,OU=automount,DC=example,DC=com' has the objectClass
>>>'automountMap' and does contain the attribute
'automountMapName' this
>>>contains 'auto.shares' not
>>>'OU=auto.master,OU=automount,DC=example,DC=com'.
>>>
>>>The problem, as I see it, is that in LDAP you can have a DN such as
>>>'automountMapName=auto.master,cn=automount,dc=example,dc=com', but
this
>>>would seem to be not allowed in AD, I cannot add an ldif using such a
>>>template
>>>
>>>I have tried both the NIS setup and the one above and they all fail in
>>>the same way for me, i.e they work perfectly if I use ldap in
>>>nsswitch.conf but will not work if I try to use sssd.
>>>
>>>Can anybody see where I am going wrong?
>>>
>>>By the way, I based this setup on a blog by some guy named Jakub Hrozek
>>>which I found here:
http://jhrozek.livejournal.com/2012/05/01/
>>>
>>>Rowland
>>>
>>>_______________________________________________
>>>sssd-users mailing list
>>>sssd-users(a)lists.fedorahosted.org
>>>https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>>_______________________________________________
>>>sssd-users mailing list
>>>sssd-users(a)lists.fedorahosted.org
>>>https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>sssd --version
>>1.10.92
>>
>>I am sure that it is something that I am doing wrong, but for the life
>>of me, I cannot see what. As I said, what ever I do, it works with
>>ldap, but as soon as sssd is asked to take control, it stops working.
>>
>>Rowland
>>
>OK, I still cannot get it to work and I have been trying to extract the
>info from AD using ldapsearch and the filter I found in the sssd logs:
>
>ldapsearch -x -h 127.0.0.1 -b OU=automount,DC=example,DC=com -D
>CN=Administrator,CN=Users,DC=example,DC=com -w xxxxxxxxxx
>'(&(automountMapName=OU=auto.master,OU=automount,DC=example,DC=com)(objectclass=automountMap))'
>
>
>This results in this:
>
># extended LDIF
>#
># LDAPv3
># base <OU=automount,DC=example,DC=com> with scope subtree
># filter:
>(&(automountMapName=OU=auto.master,OU=automount,DC=example,DC=com)(objectclass=automountMap))
># requesting: ALL
>#
>
># search result
>search: 2
>result: 0 Success
>
># numResponses: 1
>
>Or to put it another way, it returned nothing.
>
>The only way to return anything was to use either this search:
>
>ldapsearch -x -h 127.0.0.1 -b OU=automount,DC=example,DC=com -D
>CN=Administrator,CN=Users,DC=example,DC=com -w xxxxxxxxxx
>'(&(OU=auto.master)(objectclass=automountMap))'
>
>Or this search:
>
>ldapsearch -x -h 127.0.0.1 -b OU=automount,DC=example,DC=com -D
>CN=Administrator,CN=Users,DC=example,DC=com -w xxxxxxxxxx
>'(&(automountMapName=auto.master)(objectclass=automountMap))'
>
>Both of which return this:
>
># extended LDIF
>#
># LDAPv3
># base <OU=automount,DC=example,DC=com> with scope subtree
># filter: (&(automountMapName=auto.master)(objectclass=automountMap))
># requesting: ALL
>#
>
># auto.master, automount,
example.com
>dn: OU=auto.master,OU=automount,DC=example,DC=com
>objectClass: top
>objectClass: automountMap
>objectClass: organizationalUnit
>ou: auto.master
>instanceType: 4
>whenCreated: 20130917093202.0Z
>whenChanged: 20130917093202.0Z
>uSNCreated: 21811
>uSNChanged: 21811
>name: auto.master
>objectGUID:: KJf3UP15UESUsyKkGBkSZw==
>objectCategory:
>CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=example,DC=com
>automountMapName: auto.master
>distinguishedName: OU=auto.master,OU=automount,DC=example,DC=com
>
># search result
>search: 2
>result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
>I am rapidly coming to the opinion that either the search that sssd
>makes is not suitable for AD or I am doing something wrong (must admit
>that this is more likely).
>
>I repeat that if sssd is not used sssd, autofs works as expected, but if
>sssd is used then autofs does not work, so the problem, in my opinion,
>must either lie in the way that sssd connects AD to autofs or in my setup.
>
>Also please note that there are no ldap servers apart from the Samba4 AD
>in use.
>
>Is anybody else out there using samba 4, sssd and autofs (apart from
>Steve) and would care to share their setup?
>
>Rowland
>
>_______________________________________________
>sssd-users mailing list
>sssd-users(a)lists.fedorahosted.org
>https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>_______________________________________________
>sssd-users mailing list
>sssd-users(a)lists.fedorahosted.org
>https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Well, after sleeping on this problem, I had a thought, if this
ldapsearch works:
ldapsearch -x -h 127.0.0.1 -b OU=automount,DC=example,DC=com -D
CN=Administrator,CN=Users,DC=example,DC=com -w xxxxxxxxxx
'(&(automountMapName=auto.master)(objectclass=automountMap))'
What if I changed the MASTER_MAP_NAME from
"OU=auto.master,OU=automount,DC=home,DC=lan" to just "auto.master"
You did this change in /etc/sysconfig/autofs ?
We don't parse that file and as Ondrej said in another reply, currently
auto.master is the only allowed value for the master map name. (There is
a patch to add a new option to override the master map name, but still
on the devel list).