Getting cifs.idmap working on Debian

[Dave Hope]

Good day,

I am trying to use SSSD with cifsacls for an CIFS mount on Debian Buster with SSSD 1.16.

The system I'm testing with is joined to an AD domain. I can log-in with domain
credentials and check domain users with "id" or "getent passed" etc.

A CIFS share is mounted as follows, with /usr/local/etc/whisper.credentials containing an
account in the local SAM database on REMOTESERVER.

mount -t cifs //REMOTESERVER/SHARE /mnt/test -o
credentials=/usr/local/etc/whisper.credentials,noperm,cifsacl -v

getcifsacl returns the SID's, but does not resolve to names.

My assumption is therefore that cifs.idmap is not making use of the SSSD functionality. 

libwbclient.so is installed (/usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.14.0)
and has exports such as wbcLookupName. I can't spot an elf library with calls such as
cifs_idmap_init_plugin.

/etc/request-key.conf has:
create  cifs.spnego     *       *               /usr/sbin/cifs.upcall -c %k
create  dns_resolver    *       *               /usr/sbin/cifs.upcall %k

Debian's update-alternatives lists ipmap-plugin, but does not provide any alternatives
to idmapwb.so provided by cifs-utils.

sssd is configured with id_provider = ad , ldap_id_mappinng = True ,
use_fully_qualified_names = True

winbind / samba is not installed.

Would someone mind providing guidance on how best to proceed in troubleshooting the issue?

[Sumit Bose]

On Mon, Mar 11, 2019 at 06:26:34PM -0000, Dave Hope wrote:
>  Good day,
>  
>  I am trying to use SSSD with cifsacls for an CIFS mount on Debian Buster with SSSD 1.16.
>  
>  The system I'm testing with is joined to an AD domain. I can log-in with domain
> credentials and check domain users with "id" or "getent passed" etc.
>  
>  A CIFS share is mounted as follows, with /usr/local/etc/whisper.credentials containing an
> account in the local SAM database on REMOTESERVER.
>  
>  mount -t cifs //REMOTESERVER/SHARE /mnt/test -o
> credentials=/usr/local/etc/whisper.credentials,noperm,cifsacl -v
>  
>  getcifsacl returns the SID's, but does not resolve to names.
>  
>  My assumption is therefore that cifs.idmap is not making use of the SSSD functionality. 
>  
>  libwbclient.so is installed
> (/usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.14.0) and has exports such as
> wbcLookupName. I can't spot an elf library with calls such as cifs_idmap_init_plugin.
>  
>  /etc/request-key.conf has:
>  create  cifs.spnego     *       *               /usr/sbin/cifs.upcall -c %k
>  create  dns_resolver    *       *               /usr/sbin/cifs.upcall %k
>  
>  Debian's update-alternatives lists ipmap-plugin, but does not provide any
> alternatives to idmapwb.so provided by cifs-utils. 
The plugin is /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so
from the sssd-common package.

HTH

bye,
Sumit

> 
> sssd is configured with id_provider = ad , ldap_id_mappinng = True ,
use_fully_qualified_names = True
> 
> winbind / samba is not installed.
> 
> Would someone mind providing guidance on how best to proceed in troubleshooting the
issue?
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/[e-mail]...

[Dave Hope]

>  The plugin is /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so
>  from the sssd-common package.
>  
>  HTH 
Thanks! - I'd not thought to check that location. Having created a symlink to replace
the default idmap-plugin, getcifsacls now resolves the SIDs.

The actual ability to create/delete files still seems to come from the account that
mounted the share rather than the user themselves - is that expected? If so, does SSSD
support the "multiuser" option without each user/PAM having to provide
cifscreds?

Thanks

Dave

[Sumit Bose]

On Tue, Mar 12, 2019 at 08:22:37AM -0000, Dave Hope wrote:
>  > The plugin is
> /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so
>  > from the sssd-common package.
>  > 
>  > HTH
>  
>  Thanks! - I'd not thought to check that location. Having created a symlink to replace
> the default idmap-plugin, getcifsacls now resolves the SIDs.
>  
>  The actual ability to create/delete files still seems to come from the account that
> mounted the share rather than the user themselves - is that expected? If so, does SSSD
> support the "multiuser" option without each user/PAM having to provide
> cifscreds? 
If I understand the "multiuser" option correctly it should be possible
to use Kerberos credentials stored during login if sec=krb5 or sec=krb5i
is used. For NTLM there is pam_cifscreds which can be added to the PAM
configuration. You might have to add the 'forward_pass' to pam_sss.so in
the auth section as well to make sure pam_sss will put the password on
the PAM stack for other modules.

HTH

bye,
Sumit

> 
> Thanks
> 
> Dave
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/[e-mail]...

[John Hodrien]

On Tue, 12 Mar 2019, Sumit Bose wrote:

>  If I understand the "multiuser" option correctly it should
> be possible
>  to use Kerberos credentials stored during login if sec=krb5 or sec=krb5i
>  is used. For NTLM there is pam_cifscreds which can be added to the PAM
>  configuration. You might have to add the 'forward_pass' to pam_sss.so in
>  the auth section as well to make sure pam_sss will put the password on
>  the PAM stack for other modules. 
You do indeed understand the option correctly.  We use sec=krb5,multiuser
quite happily that way, getcifsacl returns sensible information, and access is
controlled using per-user krb5 as expected.

jh

[Dave Hope]

>  If I understand the "multiuser" option correctly it should
> be possible
>  to use Kerberos credentials stored during login if sec=krb5 or sec=krb5i
>  is used. For NTLM there is pam_cifscreds which can be added to the PAM
>  configuration. You might have to add the 'forward_pass' to pam_sss.so in
>  the auth section as well to make sure pam_sss will put the password on
>  the PAM stack for other modules. 
Thanks - that was the final piece of the magic. Thanks for all your assistance.