We are in the process of attempting to transition to SSSD mainly as we like the idea of a single configuration file.
We currently have two ldap servers (this cannot be changed) where one is used for user authentication and the other provides information on automounts. The ldap server used for automounts only contains a subset of the users in the other ldap server as not all users are able to, or have the need to, log into our systems.
So far we have been unsuccessful in getting SSSD to work for both authentication and autofs. We can get them to work independently but no amount of Googling has come up with a solution as how to combine the two.
All users share the same username in both servers and uid although the gid must come from the automount ldap server (both uid and gid are the same actually). Our conf file so far is given below with some information redacted.
Is it possible to combine the information from both the ldap servers using SSSD?
[sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam, autofs
domains = authd, autofsd
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[autofs]
[domain/autofsd] ldap_id_use_start_tls = True cache_credentials = False ldap_search_base = dc=test,dc=example.com ldap_uri = ldap://ldap1.example.com/ ldap_tls_cacert = /etc/ssl/certs/example.pem id_provider = ldap autofs_provider = ldap ldap_autofs_search_base = dc=test,dc=example.com
[domain/authd] ldap_id_use_start_tls = True cache_credentials = False ldap_search_base = dc=test,dc=example.com enumerate = False chpass_provider = ldap id_provider = ldap auth_provider = ldap ldap_uri = ldap://ldap2.example.com/ ldap_tls_cacert = /etc/ssl/certs/example.pem autofs_provider = none
Matt John wrote:
We currently have two ldap servers (this cannot be changed) where one is used for user authentication and the other provides information on automounts. The ldap server used for automounts only contains a subset of the users in the other ldap server as not all users are able to, or have the need to, log into our systems.
Disclaimer: I have no personal experience with multi-domain sssd config for distributed users/groups/sudoers/automap entries (except local and LDAP being used side-by-side).
But for forcing all user information to come from the [domain/authd] I'd try to set:
[domain/autofsd] [..] id_provider = none auth_provider = none [..]
Ciao, Michael.
On 25 Mar 2015, at 20:53, Michael Ströder michael@stroeder.com wrote:
Matt John wrote:
We currently have two ldap servers (this cannot be changed) where one is used for user authentication and the other provides information on automounts. The ldap server used for automounts only contains a subset of the users in the other ldap server as not all users are able to, or have the need to, log into our systems.
Disclaimer: I have no personal experience with multi-domain sssd config for distributed users/groups/sudoers/automap entries (except local and LDAP being used side-by-side).
But for forcing all user information to come from the [domain/authd] I'd try to set:
[domain/autofsd] [..] id_provider = none auth_provider = none [..]
Setting those options for the autofsd results in sssd failing to start. Looking through the logs nothing jumps out apart form these lines:
[sssd[be[autofsd]]] [be_process_init] (0x0010): fatal error initializing data providers [sssd[be[autofsd]]] [main] (0x0010): Could not initialize backend [2] [sssd] [sbus_dispatch] (0x0080): Connection is not open for dispatching. [sssd] [mt_svc_exit_handler] (0x0040): Child [autofsd] exited with code [3] [sssd] [mt_svc_exit_handler] (0x0010): Process [autofsd], definitely stopped!
On 03/25/2015 05:13 PM, Matt John wrote:
On 25 Mar 2015, at 20:53, Michael Ströder michael@stroeder.com wrote:
Matt John wrote:
We currently have two ldap servers (this cannot be changed) where one is used for user authentication and the other provides information on automounts. The ldap server used for automounts only contains a subset of the users in the other ldap server as not all users are able to, or have the need to, log into our systems.
Disclaimer: I have no personal experience with multi-domain sssd config for distributed users/groups/sudoers/automap entries (except local and LDAP being used side-by-side).
But for forcing all user information to come from the [domain/authd] I'd try to set:
[domain/autofsd] [..] id_provider = none auth_provider = none [..]
Setting those options for the autofsd results in sssd failing to start. Looking through the logs nothing jumps out apart form these lines:
[sssd[be[autofsd]]] [be_process_init] (0x0010): fatal error initializing data providers [sssd[be[autofsd]]] [main] (0x0010): Could not initialize backend [2] [sssd] [sbus_dispatch] (0x0080): Connection is not open for dispatching. [sssd] [mt_svc_exit_handler] (0x0040): Child [autofsd] exited with code [3] [sssd] [mt_svc_exit_handler] (0x0010): Process [autofsd], definitely stopped!
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Based on what I know about SSSD it might currently assume that automount data and user data come from the same identity source and share same connection. But I would leave to SSSD gurus provide more details in the morning.
On Wed, Mar 25, 2015 at 07:46:31PM -0400, Dmitri Pal wrote:
On 03/25/2015 05:13 PM, Matt John wrote:
On 25 Mar 2015, at 20:53, Michael Ströder michael@stroeder.com wrote:
Matt John wrote:
We currently have two ldap servers (this cannot be changed) where one is used for user authentication and the other provides information on automounts. The ldap server used for automounts only contains a subset of the users in the other ldap server as not all users are able to, or have the need to, log into our systems.
Disclaimer: I have no personal experience with multi-domain sssd config for distributed users/groups/sudoers/automap entries (except local and LDAP being used side-by-side).
But for forcing all user information to come from the [domain/authd] I'd try to set:
[domain/autofsd] [..] id_provider = none auth_provider = none [..]
Setting those options for the autofsd results in sssd failing to start. Looking through the logs nothing jumps out apart form these lines:
[sssd[be[autofsd]]] [be_process_init] (0x0010): fatal error initializing data providers [sssd[be[autofsd]]] [main] (0x0010): Could not initialize backend [2] [sssd] [sbus_dispatch] (0x0080): Connection is not open for dispatching. [sssd] [mt_svc_exit_handler] (0x0040): Child [autofsd] exited with code [3] [sssd] [mt_svc_exit_handler] (0x0010): Process [autofsd], definitely stopped!
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Based on what I know about SSSD it might currently assume that automount data and user data come from the same identity source and share same connection. But I would leave to SSSD gurus provide more details in the morning.
I guess we require id_provider to be != none. Sorry, then I lead you down the wrong path a bit on serverfault. The requirement might be a relic from the past where domains only served identity and authentication -- I guess it's time to change it, can you open a ticket?
Also can you try a config like this (again, untested): [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam, autofs
domains = authd, autofsd
[nss] filter_groups = root filter_users = root
[pam]
[autofs]
[domain/autofsd] # The local database would be empty id_provider = local auth_provider = none ldap_id_use_start_tls = True cache_credentials = False # You can also set the ldap_search_base to a part of the tree that only serves autofs data ldap_search_base = dc=test,dc=example.com ldap_uri = ldap://ldap1.example.com/ ldap_tls_cacert = /etc/ssl/certs/example.pem autofs_provider = ldap ldap_autofs_search_base = dc=test,dc=example.com
[domain/authd] # This domain is unchanged
It seems that auth_provider cannot be none when using local as the id_provider.
[sssd] [confdb_get_domain_internal] (0x0010): Local ID provider does not support [none] as an AUTH provider. [sssd] [confdb_get_domains] (0x0010): Error (22 [Invalid argument]) retrieving domain [autofsd], skipping!
On Thu, 26 Mar, 2015 at 9:18 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Wed, Mar 25, 2015 at 07:46:31PM -0400, Dmitri Pal wrote:
On 03/25/2015 05:13 PM, Matt John wrote:
On 25 Mar 2015, at 20:53, Michael Ströder michael@stroeder.com
wrote:
Matt John wrote:
We currently have two ldap servers (this cannot be changed)
where one is
used for user authentication and the other provides information
on
automounts. The ldap server used for automounts only contains a
subset of
the users in the other ldap server as not all users are able to,
or have
the need to, log into our systems.
Disclaimer: I have no personal experience with multi-domain sssd
config for distributed users/groups/sudoers/automap entries (except local and LDAP being used side-by-side).
But for forcing all user information to come from the
[domain/authd] I'd try to set:
[domain/autofsd] [..] id_provider = none auth_provider = none [..]
Setting those options for the autofsd results in sssd failing to
start. Looking through the logs nothing jumps out apart form these lines:
[sssd[be[autofsd]]] [be_process_init] (0x0010): fatal error
initializing data providers
[sssd[be[autofsd]]] [main] (0x0010): Could not initialize backend
[2]
[sssd] [sbus_dispatch] (0x0080): Connection is not open for
dispatching.
[sssd] [mt_svc_exit_handler] (0x0040): Child [autofsd] exited with
code [3]
[sssd] [mt_svc_exit_handler] (0x0010): Process [autofsd],
definitely stopped!
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Based on what I know about SSSD it might currently assume that automount data and user data come from the same identity source and share same connection. But I would leave to SSSD gurus provide more details in the morning.
I guess we require id_provider to be != none. Sorry, then I lead you down the wrong path a bit on serverfault. The requirement might be a relic from the past where domains only served identity and authentication -- I guess it's time to change it, can you open a ticket?
Also can you try a config like this (again, untested): [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam, autofs
domains = authd, autofsd
[nss] filter_groups = root filter_users = root
[pam]
[autofs]
[domain/autofsd] # The local database would be empty id_provider = local auth_provider = none ldap_id_use_start_tls = True cache_credentials = False # You can also set the ldap_search_base to a part of the tree that only serves autofs data ldap_search_base = dc=test,dc=example.com ldap_uri = ldap://ldap1.example.com/ ldap_tls_cacert = /etc/ssl/certs/example.pem autofs_provider = ldap ldap_autofs_search_base = dc=test,dc=example.com
[domain/authd] # This domain is unchanged _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Mar 26, 2015 at 09:25:34AM +0000, Matt John wrote:
It seems that auth_provider cannot be none when using local as the id_provider.
[sssd] [confdb_get_domain_internal] (0x0010): Local ID provider does not support [none] as an AUTH provider. [sssd] [confdb_get_domains] (0x0010): Error (22 [Invalid argument]) retrieving domain [autofsd], skipping!
Ugh, another subtle bug :-)
auth_provider=local would work as well, then. Also setting the ldap_search_base to some part of subtree that doesn't hit the users would "solve" the problem, but nonexisting entries would fire two ldap searches in this case against both of the domains.
On Thu, 26 Mar, 2015 at 9:28 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 26, 2015 at 09:25:34AM +0000, Matt John wrote:
It seems that auth_provider cannot be none when using local as the id_provider.
[sssd] [confdb_get_domain_internal] (0x0010): Local ID provider does not support [none] as an AUTH provider. [sssd] [confdb_get_domains] (0x0010): Error (22 [Invalid argument]) retrieving domain [autofsd], skipping!
Ugh, another subtle bug :-)
auth_provider=local would work as well, then. Also setting the ldap_search_base to some part of subtree that doesn't hit the users would "solve" the problem, but nonexisting entries would fire two ldap searches in this case against both of the domains.
When auth_provider is set to local no automount information is returned at all.
(Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache(Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache
On Thu, Mar 26, 2015 at 10:21:14AM +0000, Matt John wrote:
On Thu, 26 Mar, 2015 at 9:28 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 26, 2015 at 09:25:34AM +0000, Matt John wrote:
It seems that auth_provider cannot be none when using local as the id_provider. [sssd] [confdb_get_domain_internal] (0x0010): Local ID provider does not support [none] as an AUTH provider. [sssd] [confdb_get_domains] (0x0010): Error (22 [Invalid argument]) retrieving domain [autofsd], skipping!
Ugh, another subtle bug :-)
auth_provider=local would work as well, then. Also setting the ldap_search_base to some part of subtree that doesn't hit the users would "solve" the problem, but nonexisting entries would fire two ldap searches in this case against both of the domains.
When auth_provider is set to local no automount information is returned at all.
(Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache(Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache
OK, the only way I could get the config to work was:
[domain/autofsdomain] id_provider=ldap auth_provider=none autofs_provider=ldap
ldap_user_search_base = dc=no,dc=such,dc=object ldap_group_search_base = dc=no,dc=such,dc=object ldap_autofs_search_base = dc=linux,dc=test ldap_uri = ldap://ipa2.linux.test
so both identity requests and autofs requests will make it to the second domain..there is just a phony user search base to make sure no users can match the LDAP server entries.
I still consider it a bug that SSSD doesn't allow setting auth_provider=none.
btw I remembered why id_provider=local didn't work -- unlike the other providers, it's not a real back end, just a hardcoded one.
On Thu, 26 Mar, 2015 at 3:30 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 26, 2015 at 10:21:14AM +0000, Matt John wrote:
On Thu, 26 Mar, 2015 at 9:28 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 26, 2015 at 09:25:34AM +0000, Matt John wrote:
It seems that auth_provider cannot be none when using local as
the
id_provider. [sssd] [confdb_get_domain_internal] (0x0010): Local ID
provider does
not support [none] as an AUTH provider. [sssd] [confdb_get_domains] (0x0010): Error (22 [Invalid
argument])
retrieving domain [autofsd], skipping!
Ugh, another subtle bug :-)
auth_provider=local would work as well, then. Also setting the ldap_search_base to some part of subtree that doesn't hit the users would "solve" the problem, but nonexisting entries would fire two
ldap
searches in this case against both of the domains.
When auth_provider is set to local no automount information is returned at all.
(Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache(Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache
OK, the only way I could get the config to work was:
[domain/autofsdomain] id_provider=ldap auth_provider=none autofs_provider=ldap
ldap_user_search_base = dc=no,dc=such,dc=object ldap_group_search_base = dc=no,dc=such,dc=object ldap_autofs_search_base = dc=linux,dc=test ldap_uri = ldap://ipa2.linux.test
so both identity requests and autofs requests will make it to the second domain..there is just a phony user search base to make sure no users can match the LDAP server entries.
I still consider it a bug that SSSD doesn't allow setting auth_provider=none.
btw I remembered why id_provider=local didn't work -- unlike the other providers, it's not a real back end, just a hardcoded one.
Thanks that worked great! We are able to successfully authenticate and mount home directories using that set up which is half the battle :)
We need the group id and groups to come from the autofs domain which at the moment is not happening. Is is possible to do this?
On Thu, Mar 26, 2015 at 03:56:04PM +0000, Matt John wrote:
On Thu, 26 Mar, 2015 at 3:30 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 26, 2015 at 10:21:14AM +0000, Matt John wrote:
On Thu, 26 Mar, 2015 at 9:28 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 26, 2015 at 09:25:34AM +0000, Matt John wrote:
It seems that auth_provider cannot be none when using local as the id_provider. [sssd] [confdb_get_domain_internal] (0x0010): Local ID provider
does
not support [none] as an AUTH provider. [sssd] [confdb_get_domains] (0x0010): Error (22 [Invalid argument]) retrieving domain [autofsd], skipping!
Ugh, another subtle bug :-)
auth_provider=local would work as well, then. Also setting the ldap_search_base to some part of subtree that doesn't hit the users would "solve" the problem, but nonexisting entries would fire two ldap searches in this case against both of the domains.
When auth_provider is set to local no automount information is returned at all. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache(Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache
OK, the only way I could get the config to work was:
[domain/autofsdomain] id_provider=ldap auth_provider=none autofs_provider=ldap
ldap_user_search_base = dc=no,dc=such,dc=object ldap_group_search_base = dc=no,dc=such,dc=object ldap_autofs_search_base = dc=linux,dc=test ldap_uri = ldap://ipa2.linux.test
so both identity requests and autofs requests will make it to the second domain..there is just a phony user search base to make sure no users can match the LDAP server entries.
I still consider it a bug that SSSD doesn't allow setting auth_provider=none.
btw I remembered why id_provider=local didn't work -- unlike the other providers, it's not a real back end, just a hardcoded one.
Thanks that worked great! We are able to successfully authenticate and mount home directories using that set up which is half the battle :)
We need the group id and groups to come from the autofs domain which at the moment is not happening. Is is possible to do this?
Only groups but not users? Then I guess you just need to set the search bases to something sensible?
On 03/26/2015 11:56 AM, Matt John wrote:
On Thu, 26 Mar, 2015 at 3:30 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Mar 26, 2015 at 10:21:14AM +0000, Matt John wrote:
On Thu, 26 Mar, 2015 at 9:28 AM, Jakub Hrozek <jhrozek@redhat.com> wrote: >On Thu, Mar 26, 2015 at 09:25:34AM +0000, Matt John wrote: >> It seems that auth_provider cannot be none when using local as the >> id_provider. >> [sssd] [confdb_get_domain_internal] (0x0010): Local ID provider does >>not >> support [none] as an AUTH provider. >> [sssd] [confdb_get_domains] (0x0010): Error (22 [Invalid argument]) >> retrieving domain [autofsd], skipping! > >Ugh, another subtle bug :-) > >auth_provider=local would work as well, then. Also setting the >ldap_search_base to some part of subtree that doesn't hit the users >would "solve" the problem, but nonexisting entries would fire two ldap >searches in this case against both of the domains. When auth_provider is set to local no automount information is returned at all. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cache(Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [setautomntent_send] (0x0400): Requesting info for automount map [auto.master] from [<ALL>] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [autofsd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0400): Requesting info for [auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sysdb_get_map_byname] (0x0400): No such map (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_step] (0x0080): No automount map [auto.master] in cache for domain [authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_get_autofs_msg] (0x0400): Creating autofs request for [cardiff][4105][mapname=auto.master] (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40c040:0:auto.master@authd] (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0400): Entering be_autofs_handler() (Thu Mar 26 10:07:59 2015) [sssd[be[authd]]] [be_autofs_handler] (0x0020): Undefined backend target. (Thu Mar 26 10:07:59 2015) [sssd[autofs]] [lookup_automntmap_cache_updated] (0x0020): Unable to get information from Data Provider Error: 3, 19, Autofs back end target is not configured Will try to return what we have in cacheOK, the only way I could get the config to work was: [domain/autofsdomain] id_provider=ldap auth_provider=none autofs_provider=ldap ldap_user_search_base = dc=no,dc=such,dc=object ldap_group_search_base = dc=no,dc=such,dc=object ldap_autofs_search_base = dc=linux,dc=test ldap_uri = ldap://ipa2.linux.test so both identity requests and autofs requests will make it to the second domain..there is just a phony user search base to make sure no users can match the LDAP server entries. I still consider it a bug that SSSD doesn't allow setting auth_provider=none. btw I remembered why id_provider=local didn't work -- unlike the other providers, it's not a real back end, just a hardcoded one.
Thanks that worked great! We are able to successfully authenticate and mount home directories using that set up which is half the battle :)
We need the group id and groups to come from the autofs domain which at the moment is not happening. Is is possible to do this?
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Would you be so kind to contribute your setup as a wiki HOWTO?
On 03/26/2015 03:31 PM, Matt John wrote:
Would you be so kind to contribute your setup as a wiki HOWTO?
Yes, that won’t be a problem. I am still having some issues getting the group id to come from the autofs domain rather than the auth domain. Once I resolve this issue I will contribute the setup.
Thanks!
On Thu, Mar 26, 2015 at 03:46:00PM -0400, Dmitri Pal wrote:
On 03/26/2015 03:31 PM, Matt John wrote:
Would you be so kind to contribute your setup as a wiki HOWTO?
Yes, that won’t be a problem. I am still having some issues getting the group id to come from the autofs domain rather than the auth domain. Once I resolve this issue I will contribute the setup.
Thanks!
did setting the group search base help?
It would also be nice if you could reply once again to the original ServerFault question, since the conversation started there..
did setting the group search base help?
The issue seems to be that without a valid user search base on the autofs domain the search for groups fails as the initial search for users returns no results. It then switches to the auth domain and pulls out the wrong groups.
What we are aiming for is really to only get password information from the auth domain and get everything else from the autofs domain.
It would also be nice if you could reply once again to the original ServerFault question, since the conversation started there..
Will do!
On Fri, Mar 27, 2015 at 10:36:01AM +0000, Matt John wrote:
did setting the group search base help?
The issue seems to be that without a valid user search base on the autofs domain the search for groups fails as the initial search for users returns no results. It then switches to the auth domain and pulls out the wrong groups.
What we are aiming for is really to only get password information from the auth domain and get everything else from the autofs domain.
Hm, sorry, I'm starting to be a bit confused about what should be pulled from the first domain -- what exactly do you mean by 'password information'. The set of data that is normally returned by 'getent passwd $user' ?
It would also be nice if you could reply once again to the original ServerFault question, since the conversation started there..
Will do!
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hm, sorry, I'm starting to be a bit confused about what should be pulled from the first domain -- what exactly do you mean by 'password information'. The set of data that is normally returned by 'getent passwd $user' ?
Sorry, I shall outline the details below.
autofs domain - automount information - group information
auth domain - used for authentication only
For a bit more context we are in a university environment where central IT hold users passwords. Our department then has it's own ldap server for storing linux home directory mount information and the groups. In an ideal scenario our ldap server would be checked first and if authentication fails the central IT ldap server should be queried.
Does this make a bit more sense?
Matt John wrote:
For a bit more context we are in a university environment where central IT hold users passwords. Our department then has it's own ldap server for storing linux home directory mount information and the groups. In an ideal scenario our ldap server would be checked first and if authentication fails the central IT ldap server should be queried.
Password authentication is *not* getent passwd.
If all your posixAccount user entries are in your own "autofs" directory I'd look into simply chaining the password checking to the central LDAP directory. The technical options depend on your LDAP server used.
Ciao, Michael.
On Fri, Mar 27, 2015 at 02:25:48PM +0100, Michael Ströder wrote:
Matt John wrote:
For a bit more context we are in a university environment where central IT hold users passwords. Our department then has it's own ldap server for storing linux home directory mount information and the groups. In an ideal scenario our ldap server would be checked first and if authentication fails the central IT ldap server should be queried.
Password authentication is *not* getent passwd.
If all your posixAccount user entries are in your own "autofs" directory I'd look into simply chaining the password checking to the central LDAP directory. The technical options depend on your LDAP server used.
Ciao, Michael.
Right. The only way I can currently think of on the client side to authenticate against a different LDAP server than the users are retrieved from would be with auth_provider=proxy that would proxy to pam_ldap (or with very new SSSD versions that can limit certain PAM services to certain PAM domains also pam_sss) that would redirect auth to the central LDAP server.
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Matt John -
Michael Ströder