Hello all, hope all is well/happy holidays
Checked on the samba list and they directed me here..... My issue is valid users in smb.conf containing an AD group
I have tried this on systems running cent7u2 and ubuntu trusty. These systems are running sssd. I can login with AD users and chown/chgrp file with AD groups. However, I can't get AD groups to work with valid users in the smb.conf for restricting share access. If I just set individual AD users, works just fine.
Also locally everything works as expected. For example I can chown a folder to be owned by an AD group with 2770. I can login into the host via passwd/kerberos ticket and chdir into that directly without issue, below the user in question is part of MC-Services, apologies not trying to be overly obvious.
drwxrwsr-x 3 appadmin MC-Services 4096 Dec 15 14:47 logs
Again singly listed AD users work with valid users. This kind of abstraction is nice so I don't have to tweak FS perms to "match" shared out access. Right now with the local FS perms above I can get into the share If I have the share setup as below
[logs] comment = Server Logs path = /logs writable = no valid users = jsmith printable = no
So seems samba can handle the users, but not AD groups or can't get the info/membership for the AD groups. If I change the owner of the dir to be completely owned by appadmin, the testing user can no longer get into the share, make sense.
Any thoughts/help would be greatly appreciated. thanks and regards
some info on samba vers on the centos host
samba-common-4.2.3-12.el7_2.noarch samba-common-tools-4.2.3-12.el7_2.x86_64 samba-common-libs-4.2.3-12.el7_2.x86_64 samba-4.2.3-12.el7_2.x86_64 samba-libs-4.2.3-12.el7_2.x86_64 samba-client-libs-4.2.3-12.el7_2.x86_64
[root@Xsamba]# smbd -V Version 4.2.3
Here is the SAMBA config
[global] workgroup = mc server string = Samba Server Version %v log file = /var/log/samba/log.%m max log size = 50 security = ads bind interfaces only = yes interfaces=192.168.99.0/24 dedicated keytab file=/etc/krb5.keytab password server = 192.168.1.2 192.168.1.3 realm = MC.FOO.COM passdb backend = tdbsam map to guest = Bad Uid
[homes] comment = Home Directories browseable = no writable = yes
[logs] comment = Server Logs path = /logs writable = no #valid users = jsmith valid users = @"MC\MC-Services" printable = no
On Thu, Dec 15, 2016 at 10:28:06PM -0000, js16uy@gmail.com wrote:
Hello all, hope all is well/happy holidays
Checked on the samba list and they directed me here..... My issue is valid users in smb.conf containing an AD group
I have tried this on systems running cent7u2 and ubuntu trusty. These systems are running sssd. I can login with AD users and chown/chgrp file with AD groups. However, I can't get AD groups to work with valid users in the smb.conf for restricting share access. If I just set individual AD users, works just fine.
Also locally everything works as expected. For example I can chown a folder to be owned by an AD group with 2770. I can login into the host via passwd/kerberos ticket and chdir into that directly without issue, below the user in question is part of MC-Services, apologies not trying to be overly obvious.
drwxrwsr-x 3 appadmin MC-Services 4096 Dec 15 14:47 logs
Again singly listed AD users work with valid users. This kind of abstraction is nice so I don't have to tweak FS perms to "match" shared out access. Right now with the local FS perms above I can get into the share If I have the share setup as below
[logs] comment = Server Logs path = /logs writable = no valid users = jsmith printable = no
So seems samba can handle the users, but not AD groups or can't get the info/membership for the AD groups. If I change the owner of the dir to be completely owned by appadmin, the testing user can no longer get into the share, make sense.
Any thoughts/help would be greatly appreciated. thanks and regards
some info on samba vers on the centos host
samba-common-4.2.3-12.el7_2.noarch samba-common-tools-4.2.3-12.el7_2.x86_64 samba-common-libs-4.2.3-12.el7_2.x86_64 samba-4.2.3-12.el7_2.x86_64 samba-libs-4.2.3-12.el7_2.x86_64 samba-client-libs-4.2.3-12.el7_2.x86_64
[root@Xsamba]# smbd -V Version 4.2.3
Here is the SAMBA config
[global] workgroup = mc server string = Samba Server Version %v log file = /var/log/samba/log.%m max log size = 50 security = ads bind interfaces only = yes interfaces=192.168.99.0/24 dedicated keytab file=/etc/krb5.keytab password server = 192.168.1.2 192.168.1.3 realm = MC.FOO.COM passdb backend = tdbsam map to guest = Bad Uid
[homes] comment = Home Directories browseable = no writable = yes
[logs] comment = Server Logs path = /logs writable = no #valid users = jsmith valid users = @"MC\MC-Services" printable = no
Is there anything related in the samba logs? You might need to increase the log level to get more details?
How does the sssd.conf look like?
Does "getent group 'MC\MC-Services'" return the expected group?
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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:
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=com?subtree?&(objectClass=top)(!(objectClass=computer))(gidnumber=*)(|(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,
On Fri, Dec 16, 2016 at 04:33:37PM -0000, js16uy@gmail.com 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=com?subtree?&(objectClass=top)(!(objectClass=computer))(gidnumber=*)(|(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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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 sbose@redhat.com wrote:
On Fri, Dec 16, 2016 at 04:33:37PM -0000, js16uy@gmail.com 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=
com?subtree?&(objectClass=top)(!(objectClass=computer))( gidnumber=*)(|(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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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 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= com?subtree?&(objectClass=top)(!(objectClass=computer))( gidnumber=*)(|(groupType<=0)(&(objectClass=user)(objectCategory=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 js16uy@gmail.com 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 sbose@redhat.com wrote:
On Fri, Dec 16, 2016 at 04:33:37PM -0000, js16uy@gmail.com 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)(objectCatego ry=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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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 js16uy@gmail.com 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 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 js16uy@gmail.com 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 sbose@redhat.com wrote:
On Fri, Dec 16, 2016 at 04:33:37PM -0000, js16uy@gmail.com 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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 js16uy@gmail.com 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 js16uy@gmail.com 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 sbose@redhat.com wrote:
On Fri, Dec 16, 2016 at 04:33:37PM -0000, js16uy@gmail.com 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Thanks very much for all the help reset my vms back to ground state and used the AD as the provider Works. I think in my testing I had the FS perms to tight after testing.
thanks again for the time and the help
On Tue, Dec 20, 2016 at 4:12 AM, Sumit Bose sbose@redhat.com wrote:
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 js16uy@gmail.com 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 js16uy@gmail.com
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 sbose@redhat.com
wrote:
On Fri, Dec 16, 2016 at 04:33:37PM -0000, js16uy@gmail.com 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.
fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
jsl6uy js16uy -
Sumit Bose