[Freeipa-users] authenticate samba 3 or 4 with freeipa: building ipasam.so on Ubuntu

Alexander Bokovoy abokovoy at redhat.com
Tue Jan 20 08:01:43 UTC 2015


On Wed, 14 Jan 2015, Raoul Becke wrote:
>Alexander Bokovoy <abokovoy at ...> writes:
>
>>
>> On Fri, 28 Mar 2014, Jason Woods wrote:
>> >Hi
>> >(Apologies - resending to the list - I'm so used to the Reply-To already
>set but it appears not to be here my bad.)
>> >
>> >> On 28 Mar 2014, at 11:32, Petr Spacek <pspacek at ...> wrote:
>> >>
>> >> Please let us know if it worked for you or not. I'm curious!
>> >
>> >I'm pretty curious too.
>> >
>> >I have RHEL 6.5 with samba authenticating with IPA using ipasam.so. I
>> >needed to add two patches though to 3.0 to fix 'valid users' group
>> >resolution and also performance. They're merged into master and 3.3
>> >and will be in RHEL 7.
>> >
>> >Apart from the patching it was easy to do - just needed ipa-server and
>> >ipa-server-adtrust installed and setup and it did all the config for me
>> >(the adtrust part sets up samba with ipasam.so for you).
>> >
>> >Problem is running ipasam.so without the ipa-server locally - is how to
>> >get it so the host can see ipaNTHash in the schema to check password.
>> >If ipa-server is local the host has access, otherwise it doesn't.
>> >
>> >So be good to find out what aci or service principal stuff makes that
>> >available in an elegant and secure way.
>> We have https://fedorahosted.org/freeipa/ticket/3999 for documenting it
>> all and may be creating a simple configuration tool.
>>
>> Timing is not yet defined.
>>
>
>Is there any news on this issue?
Yes, the solution based on SSSD providing a winbindd-compatible
interface is available in Fedora 21 and RHEL7.1beta.

>I tried the following work-around which unfortunately did not work.
>1. On the IPA Server:
>]# yum install ipa-server-trust-ad
>2. On the IPA Server: Run "ipa-adtrust-install"
>]# ipa-adtrust-install
>3. On ipa-server: Copy "ipasam.so" to samba server:
>]# scp /usr/lib64/samba/pdb/ipasam.so file--s0-v1.becke.ch:/usr/lib64/samba/pdb/
>4. On ipa-server:Create the following CIFS service:
>]# ipa service-add cifs/file--s0-v1.becke.ch at BECKE.CH
you also need to add cifs/file--s0-v1.becke.ch at BECK.CH to an ACI that
would allow it to read ipaNTHash attribute.

>5. On ipa-server: Create keytab for samba server and copy over to samba server
>]# ipa-getkeytab -s directory--s0-v1.becke.ch -p
>cifs/file--s0-v1.becke.ch at BECKE.CH -k /tmp/samba.keytab
>]# scp /tmp/samba.keytab root at file--s0-v1.becke.ch:/etc/samba/samba.keytab
>
>6. On samba server:
>vi /etc/samba/smb.conf
>...
>[global]
>        workgroup = BECKECH
>        server string = Samba Server Version %v
>        netbios name = FILES0V1
>
>	log file = /var/log/samba/%m.log
>	max log size = 50
>
>        realm = BECKE.CH
>        kerberos method = dedicated keytab
>        dedicated keytab file = FILE:/etc/samba/samba.keytab
>        create krb5 conf = no
>
>        security = user
>
>#        passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-BECKE-CH.socket
>        passdb backend = ipasam:ldaps://directory--s0-v1.becke.ch
>
>        ldapsam:trusted=yes
>        ldap ssl = off
>        ldap suffix = dc=becke,dc=ch
>        ldap user suffix = cn=users,cn=accounts
>        ldap group suffix = cn=groups,cn=accounts
>        ldap machine suffix = cn=computers,cn=accounts
>...
>
>But all this did not help and I always get:
>]# smbclient -L file--s0-v1.becke.ch -U test--s0-v1%eo885418 -d 10
>...
>  NTLMSSP_NEGOTIATE_KEY_EXCH
>SPNEGO login failed: Logon failure
>session setup failed: NT_STATUS_LOGON_FAILURE
>...
>
>Doing the same against the IPA Server everything works fine:
># smbclient -L directory--s0-v1.becke.ch -U test--s0-v1%eo885418 -d 10
>
>... Maybe there is something wrong in: "cli_init_creds" ... but now after
>hours of research, debugging and testing I will give up and switch to
>"tdbsam" which is not optimal but should at least work ...
As I said above, your cifs/file-* service is unable to read out password
values from ipaNTHash attribute of a user entry. It has to be added
to a pre-defined group first. That group is then added into a
specialized ACI granting access to the attributes required by Samba.

It could be done through role/privilege/permission process in IPA 4.0+:

0. Add service on host foo.bar:
 # ipa service-add cifs/foo.bar

1. Add permission:
 # ipa permission-add "CIFS server can read user passwords" \
   --attrs={ipaNTHash,ipaNTSecurityIdentifier} \
   --type=user --right={read,search,compare} --bindtype=permission 

2. Add privilege:
 # ipa privilege-add-permission 'CIFS server privilege' --permission='CIFS server can read user passwords'

3. Add role to bind privilege to specific services:
 # ipa role-add 'CIFS server'
 # ipa role-add-privilege 'CIFS server' --privilege='CIFS server privilege'
 # ipa role-add-member 'CIFS server' --services=cifs/foo.bar

If you have keytab for the service cifs/foo.bar, you can verify that it
indeed can read ipaNTHash:
[root at master ~]# kdestroy -A
[root at master ~]# kinit -kt foobar.keytab cifs/foo.bar
[root at master ~]# ldapsearch -Y GSSAPI uid=admin ipaNTHash
SASL/GSSAPI authentication started
SASL username: cifs/foo.bar at F21.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=f21,dc=test> (default) with scope subtree
# filter: uid=admin
# requesting: ipaNTHash 
#

# admin, users, compat, f21.test
dn: uid=admin,cn=users,cn=compat,dc=f21,dc=test

# admin, users, accounts, f21.test
dn: uid=admin,cn=users,cn=accounts,dc=f21,dc=test
ipaNTHash:: <some base64 value>

# search result
search: 4
result: 0 Success

# numResponses: 3
# numEntries: 2

This would work more or less same in 3.0 but you would need to add
permissions differently because 3.x doesn't have as easy permission
constructing means as 4.0 has.

An approach we chose with SSSD in Fedora 21/RHEL7.1beta is totally
different -- SSSD provides needed information to perform identity
management and authentication via libwinbind replacement library. The
only issue with this approach is that NTLM authentication is not
supported, one have to use Kerberos auth all the time.

-- 
/ Alexander Bokovoy




More information about the Freeipa-users mailing list