On Wed, 14 Jan 2015, Raoul Becke wrote:
Alexander Bokovoy <abokovoy@...> 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@...> 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...@becke.ch
you also need to add cifs/file--s0-v1.becke...@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...@becke.ch -k /tmp/samba.keytab
]# scp /tmp/samba.keytab r...@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@master ~]# kdestroy -A
[root@master ~]# kinit -kt foobar.keytab cifs/foo.bar
[root@master ~]# ldapsearch -Y GSSAPI uid=admin ipaNTHash
SASL/GSSAPI authentication started
SASL username: cifs/foo....@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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to