[SSSD-users] Re: sssd + samba valid users

[Sumit Bose]

On Mon, Dec 19, 2016 at 11:07:52AM -0600, jsl6uy js16uy wrote:
> Would you have any other ideas on why, even with leveraging ad as the
> provider, samba can not see into AD groups to use in valid users for
> restricting share access?
>
> as always thanks for the help
> regards
>
> On Fri, Dec 16, 2016 at 1:53 PM, jsl6uy js16uy  wrote:
> > Unfortunately I am still seeing the same results for leveraging valid
> > users on a host configured using the ad provider
> > results from getent group
> >
> > root@X:~# getent group MC-Services
> > mc-services:*:11959:rwaer,npgast,ngon,jht,mdon,jde,cdig

Does

getent group 'MC\MC-Services'

return the same result?

Please check the samba logs file as well to see how Samba tries to
lookup the group and why it failed. You might need to increase the 'log
level'.

bye,
Sumit
> > root@chhq-vulrwrdo01:~#
> >
> > Appreciate the help in all this!
> >
> > best regards
> >
> > here is the conf
> > > > >
> >
> > [sssd]
> > config_file_version = 2
> > debug_level = 6
> > reconnection_retries = 3
> > sbus_timeout = 30
> > services = nss, pam
> > domains = foo
> >
> > [nss]
> > filter_groups = root,
> > filter_users = root,
> > reconnection_retries = 3
> >
> > [pam]
> > reconnection_retries = 3
> >
> > [domain/foo]
> > enumerate = False
> >
> > id_provider = ad
> > chpass_provider = ad
> > auth_provider = ad
> >
> > min_id = 1000
> >
> > ad_hostname = X.mc.foo.com
> > ad_domain = mc.foo.com
> >
> > dyndns_update = false
> >
> > ldap_id_mapping = false
> > ldap_user_home_directory = unixHomeDirectory
> > ldap_user_object_class = user
> > ldap_group_object_class = top
> > ldap_group_nesting_level = 5
> > ldap_group_name = sAMAccountName
> > ldap_group_search_base = ou=accounts,dc=mc,dc=foo,dc=co
> > m?subtree?&(objectClass=top)(!(objectClass=computer))(gidnum
> > ber=*)(|(groupType<=0)(&(objectClass=user)(objectCatego
> > ry=person)(uidNumber=*)))
> >
> > access_provider = simple
> > simple_allow_users = risk,risk_ra,
> > simple_allow_groups = MC-Services,DevOps,
> >
> > On Fri, Dec 16, 2016 at 12:37 PM, jsl6uy js16uy  wrote:
> > > Understood wrt to getent returning. We are actually using ad provider for
> > > our ubu systems. The reason we haven't moved completely to using ad
> > > provider is bug 1872, which we have commented on as well as others.
> > > https://fedorahosted.org/sssd/ticket/1872
> > > btw do you know if there is any forward moment on this feature with
> > > dealing with personal groups?
> > > i will try valid users on an ubu system leveraging the ad provider and
> > > report back
> > >
> > > On Fri, Dec 16, 2016 at 11:39 AM, Sumit Bose  wrote:
> > > > On Fri, Dec 16, 2016 at 04:33:37PM -0000, [e-mail] wrote:
> > > > > Thanks very much for the response! Much appreciated
> > > > > Yes it does. getent group does return the proper gid for queried groups
> > > > >
> > > > > [root@X samba]# getent group MC-Services
> > > > > MC-Services:*:11959:
> > > >
> > > > ok, But I guess "getent group 'MC\MC-Services'" (the group name you use
> > > > in smb.conf) does not return anything.
> > > >
> > > > If there a reason you use id_provider=ldap and auth_provider=krb5
> > > > instead to id_provider=ad ?
> > > >
> > > > The 'MC' before the '' is the NetBIOS domain name of the AD domain
> > > > which cannot be discovered by the plain LDAP provider but the AD
> > > > provider can. If you cannot change the provider you can try to change
> > > > the SSSD domain name in sssd.conf form 'foo' to MC. Then it should be
> > > > possible to resolve names like 'MC\MC-Services' but in general I would
> > > > recommend to try the AD provider.
> > > >
> > > > HTH
> > > >
> > > > bye,
> > > > Sumit
> > > > > Here is our sssd.conf
> > > > > > >>>
> > > > >
> > > > > [sssd]
> > > > > config_file_version = 2
> > > > > debug_level = 6
> > > > > reconnection_retries = 3
> > > > > sbus_timeout = 30
> > > > > services = nss, pam
> > > > > domains = foo
> > > > >
> > > > > [nss]
> > > > > filter_groups = root,
> > > > > filter_users = root,
> > > > > reconnection_retries = 3
> > > > >
> > > > > [pam]
> > > > > reconnection_retries = 3
> > > > >
> > > > > [domain/foo]
> > > > > enumerate = False
> > > > > id_provider = ldap
> > > > > min_id = 1000
> > > > > chpass_provider = krb5
> > > > > ldap_schema = rfc2307bis
> > > > > # currently using ldap over port 389 because ldaps over 686 returns
> > > >
> > > > 'encoded packet size too big'
> > > > > ldap_uri = ldap://dc.mc.foo.com
> > > > > ldap_search_base = ou=accounts,dc=mc,dc=foo,dc=com
> > > > > ldap_id_mapping = false
> > > > > ldap_tls_reqcert = allow
> > > > > ldap_sasl_mech = GSSAPI
> > > > > ldap_sasl_canonicalize = true
> > > > > ldap_sasl_authid = X$
> > > > > ldap_krb5_init_creds = true
> > > > > ldap_user_object_class = user
> > > > > ldap_group_object_class = top
> > > > > ldap_group_nesting_level = 5
> > > > > ldap_group_search_base = ou=accounts,dc=mc,dc=foo,dc=co
> > > >
> > > > m?subtree?&(objectClass=top)(!(objectClass=computer))(gidnum
> > > > ber=*)(|(groupType<=0)(&(objectClass=user)(objectCategory=
> > > > person)(uidNumber=*)))
> > > > > ldap_user_name = sAMAccountName
> > > > > ldap_group_name = sAMAccountName
> > > > > ldap_user_fullname = cn
> > > > > ldap_user_home_directory = unixHomeDirectory
> > > > >
> > > > > auth_provider = krb5
> > > > > krb5_server = dc.mc.foo.com:88
> > > > > krb5_realm = MC.FOO.COM
> > > > > krb5_canonicalize = false
> > > > > krb5_changepw_principal = kadmin/changepw
> > > > > krb5_auth_timeout = 15
> > > > > krb5_keytab = /etc/krb5.keytab
> > > > > krb5_validate = true
> > > > >
> > > > > access_provider = simple
> > > > > simple_allow_users =
> > > > > simple_allow_groups = MC-Services,
> > > > > > >>
> > > > >
> > > > > sssd-users mailing list -- [e-mail]
> > > > > To unsubscribe send an email to [e-mail]
> > > >
> > > > osted.org
> > > > _______________________________________________
> > > > sssd-users mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]