[SSSD-users] problem with sssd using AD on Windows server 202R2

Kristjan Elias kristjanelias at gmail.com
Thu Aug 28 16:56:04 UTC 2014


Hi,

My rhel version is:
[root at etl4 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.2 (Santiago)
[root at etl4 ~]# uname -a
Linux etl4 2.6.32-279.19.1.el6.x86_64 #1 SMP Sat Nov 24 14:35:28 EST 2012
x86_64 x86_64 x86_64 GNU/Linux

Indeed I need to avoid joining the hosts to the domain.

To describe the group topology is quite difficult as it is a huge corporate
domain and i am not strictly aware of all the groups.
Do you have more specific questions about that?

Thanks,

Kristjan






On Thu, Aug 28, 2014 at 7:26 PM, Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Thu, Aug 28, 2014 at 07:14:13PM +0300, Kristjan Elias wrote:
> > Hi all,
> >
> > I have been having some trouble lately with our setup of sssd what i will
> > try to describe for you now.
> >
> > For the past year we have been using sssd to authenticate our RHEL6 local
> > users from Corporate MS AD.
> > This has been working without any problems so far.
> >
> > Last week the last of our DC AD servers were upgraded to Windows server
> > 2012R2 and now the problems started.
> > Firstly AD performance enhancements were lost.
> >
> > Snippet from logs:
> >
> > (Wed Aug 20 12:21:17 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
> > level to [5]
> >
> > (Wed Aug 20 14:34:38 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
> > level to [5]
> >
> > (Wed Aug 20 15:22:52 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
> > level to [5]
> >
> > (Wed Aug 20 16:03:46 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
> > level to [5]
> >
> > (Wed Aug 20 16:24:53 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
> > level to [5]
> >
> > (Wed Aug 20 16:49:04 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
> > level to [5]
> >
> > (Wed Aug 20 17:45:55 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
> > level to [5]
> >
> > (Wed Aug 20 18:05:01 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility
> > level to [5]
> >
> > (Thu Aug 21 02:20:38 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0080): Received invalid value for
> AD
> > compatibility level. Continuing without AD performance enhancements
> >
> > (Thu Aug 21 04:43:38 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0080): Received invalid value for
> AD
> > compatibility level. Continuing without AD performance enhancements
> >
> > (Thu Aug 21 10:27:18 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0080): Received invalid value for
> AD
> > compatibility level. Continuing without AD performance enhancements
> >
> > (Thu Aug 21 10:32:27 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0080): Received invalid value for
> AD
> > compatibility level. Continuing without AD performance enhancements
> >
> > (Thu Aug 21 10:52:46 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0080): Received invalid value for
> AD
> > compatibility level. Continuing without AD performance enhancements
> >
> > (Thu Aug 21 16:38:27 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0080): Received invalid value for
> AD
> > compatibility level. Continuing without AD performance enhancements
> >
> > (Thu Aug 21 17:08:06 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0080): Received invalid value for
> AD
> > compatibility level. Continuing without AD performance enhancements
> >
> > (Thu Aug 21 17:41:15 2014) [sssd[be[MS_AD]]]
> > [sdap_get_server_opts_from_rootdse] (0x0080): Received invalid value for
> AD
> > compatibility level. Continuing without AD performance enhancements
> >
> >
> > For this i filed a bug:
> >
> > https://fedorahosted.org/sssd/ticket/2418
>
> I have local patches for this issue. If you tell me your RHEL versions,
> I can build you test packages right away.
>
> >
> >
> >
> > Secondly when running without AD performance enhancements all logins fail
> > when going through the users parent groups.
> >
> > This error  disables the AD login for my RHEL servers.
> >
> > Here are the failure points in sssd log for 3 different users:
> >
> >
> > From my login attempt:
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sysdb_search_group_by_name]
> > (0x0400): No such entry
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_add_incomplete_groups]
> > (0x1000): Group #34 [SKYPEDWETL4] is not cached, need to add a fake entry
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): start ldb
> > transaction (nesting: 2)
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_add_incomplete_groups]
> > (0x1000): Mapping group [FTE_europe_2] objectSID to unix ID
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_attrs_get_sid_str]
> > (0x0080): No [objectSID] attribute while id-mapping. [0][Success]
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb
> > transaction (nesting: 2)
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_nested_groups_store]
> > (0x0400): Could not add incomplete groups [2]: No such file or directory
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb
> > transaction (nesting: 1)
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [save_rfc2307bis_groups]
> > (0x0080): Could not save groups [2]: No such file or directory
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]]
> [sdap_initgr_rfc2307bis_done]
> > (0x0080): Could not save groups memberships [2](Thu Aug 28 13:59:04 2014)
> > [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0)
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_get_initgr_done]
> > (0x4000): Initgroups done
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_get_initgr_done]
> > (0x4000): Error in initgroups: [2][No such file or directory]
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_id_op_done] (0x4000):
> > releasing operation connection
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_process_result]
> > (0x2000): Trace: sh[0x23dfc50], connected[1], ops[(nil)], ldap[0x23dead0]
> >
> > (Thu Aug 28 13:59:04 2014) [sssd[be[MS_AD]]] [sdap_process_result]
> > (0x2000): Trace: ldap_result found nothing!
>
> I didn't see this problem in my testing so far. Could you describe the
> group topology a bit so that we can reproduce locally?
>
> Sorry for the trouble you're seeing..
>
> >
> >
> >
> > My colleague login attempt:
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sysdb_search_group_by_name]
> > (0x0400): No such entry
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_add_incomplete_groups]
> > (0x1000): Group #32 [SKYPEDWETL4] is not cached, need to add a fake entry
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): start ldb
> > transaction (nesting: 2)
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_add_incomplete_groups]
> > (0x1000): Mapping group [SKYPE_ES_BI_FTE] objectSID to unix ID
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_attrs_get_sid_str]
> > (0x0080): No [objectSID] attribute while id-mapping. [0][Success]
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb
> > transaction (nesting: 2)
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_nested_groups_store]
> > (0x0400): Could not add incomplete groups [2]: No such file or directory
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb
> > transaction (nesting: 1)
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [save_rfc2307bis_groups]
> > (0x0080): Could not save groups [2]: No such file or directory
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]]
> [sdap_initgr_rfc2307bis_done]
> > (0x0080): Could not save groups memberships [2](Thu Aug 28 15:22:11 2014)
> > [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0)
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_get_initgr_done]
> > (0x4000): Initgroups done
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_get_initgr_done]
> > (0x4000): Error in initgroups: [2][No such file or directory]
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_id_op_done] (0x4000):
> > releasing operation connection
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_process_result]
> > (0x2000): Trace: sh[0x23dff60], connected[1], ops[(nil)], ldap[0x23de070]
> >
> > (Thu Aug 28 15:22:11 2014) [sssd[be[MS_AD]]] [sdap_process_result]
> > (0x2000): Trace: ldap_result found nothing!
> >
> >
> >
> > Another collegue:
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sysdb_search_group_by_name]
> > (0x0400): No such entry
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_add_incomplete_groups]
> > (0x1000): Group #34 [SKYPEDW_FILESHARE_TEST_TPUM_RO] is not cached, need
> to
> > add a fake entry
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): start ldb
> > transaction (nesting: 2)
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_add_incomplete_groups]
> > (0x1000): Mapping group [SKYPE_ES_BI_FTE] objectSID to unix ID
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_attrs_get_sid_str]
> > (0x0080): No [objectSID] attribute while id-mapping. [0][Success]
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb
> > transaction (nesting: 2)
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_nested_groups_store]
> > (0x0400): Could not add incomplete groups [2]: No such file or directory
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb
> > transaction (nesting: 1)
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [save_rfc2307bis_groups]
> > (0x0080): Could not save groups [2]: No such file or directory
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]]
> [sdap_initgr_rfc2307bis_done]
> > (0x0080): Could not save groups memberships [2](Thu Aug 28 15:31:57 2014)
> > [sssd[be[MS_AD]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0)
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_get_initgr_done]
> > (0x4000): Initgroups done
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_get_initgr_done]
> > (0x4000): Error in initgroups: [2][No such file or directory]
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_id_op_done] (0x4000):
> > releasing operation connection
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_process_result]
> > (0x2000): Trace: sh[0x23dff60], connected[1], ops[(nil)], ldap[0x23de070]
> >
> > (Thu Aug 28 15:31:57 2014) [sssd[be[MS_AD]]] [sdap_process_result]
> > (0x2000): Trace: ldap_result found nothing!
> >
> >
> >
> >
> > My sssd.conf looks like this:
> > ##########################################################
> >
> > [sssd]
> >
> > domains = MS_AD
> >
> > services = nss,pam
> >
> > config_file_version = 2
> >
> >
> > [nss]
> >
> > filter_users = root,etl,gpadmin,nws
> >
> > filter_groups = root,etl,gpadmin,nws
> >
> > default_shell = /bin/bash
> >
> >
> > [pam]
> >
> > reconnection_retries = 3
> >
> > offline_credentials_expiration = 1
> >
> > offline_failed_login_attempts = 1
> >
> >
> > [domain/MS_AD]
> >
> > description = LDAP domain with MS AD server
> >
> > debug_level = 9
> >
> >
> > # caching credentials
> >
> > enumerate = false
> >
> > cache_credentials = false
> >
> >
> > min_id = 1000
> >
> >
> > id_provider = ldap
>
> I'm curious, why don't you use id_provider=ad instead?
>
> Do you need to avoid joining the Linux machine to the AD domain?
>
> Please note that the AD provider is in many respects a superset of the
> LDAP provider, so all the ldap_* options would apply, with the exception
> of the bind DN. When using the AD provider, you need to use GSSAPI
> instead.
>
> >
> > auth_provider = ldap
> >
> > chpass_provider = ldap
> >
> >
> > ldap_tls_reqcert = never
> >
> >
> > ldap_id_mapping = True
> >
> > ldap_schema = ad
> >
> > ldap_idmap_range_min = 10000
> >
> > ldap_idmap_range_max = 2000100000
> >
> > ldap_idmap_range_size = 20000000
> >
> >
> > ldap_uri = ldap://adserveraddress/
> >
> > ldap_search_base = OU=UserAccounts,DC=something,DC=something
> > ,DC=something,DC=com
> >
> > ldap_default_bind_dn = CN=Bind User Name,OU=UserAccounts,DC=something,DC=
> > something,DC=something,DC=com
> >
> > ldap_default_authtok_type = password
> >
> > ldap_default_authtok = passwordgoeshere
> >
> > ldap_user_object_class = user
> >
> > ldap_group_object_class = group
> >
> > ldap_user_name = sAMAccountName
> >
> > ldap_user_objectsid = objectSid
> >
> > ldap_group_objectsid = objectGUID
> >
> > ldap_user_search_filter = memberOf=CN=SKYPEDWETL4,OU=UserAccounts,DC=
> > something,DC=something,DC=something,DC=com
> >
> > override_homedir = /home/%u
> >
> >
> > # performance
> >
> > ldap_disable_referrals = true
> >
> > ##########################################################
> >
> >
> >
> >
> > Have any of you had experiences with errors like this?
> >
> > Many thanks for your attention!
> >
> >
> > Thanks,
> >
> >
> > Kristjan Elias
>
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> _______________________________________________
> sssd-users mailing list
> sssd-users at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-users/attachments/20140828/1a8f90d5/attachment-0001.html>


More information about the sssd-users mailing list