[Samba] kerberos + winbind + AD authentication for samba 4 domain member

Wed Nov 1 12:16:37 UTC 2017

Also I rushed my response:

Behaviour is not strange, default principal was taken from cache.

So if run:

[DOMAIN\kacper_wirski at vs-files ~]$ kdestroy

Error returns (kinit uses DOMAINkacper_wirski at AD.MYDOMAIN.COM as 
kerberos principal).

W dniu 2017-11-01 o 13:11, Kacper Wirski pisze:
>
> Hello,
>
> Thank You for fast response. I'm glad that it's a mistake somewhere on 
> my side, it means it will work when I fix it :)
>
> Ok, first of all:
>
>
> Everything is on centos 7.4
>
> All config files will be below, but to start off: behaviour is 
> stranger than I thought, but there is a pattern:
>
> when doing
>
> [DOMAIN\kacper_wirski at vs-files ~]$ kinit -V
> Using default cache: /tmp/krb5cc_101003
> Using principal: DOMAINkacper_wirski at AD.MYDOMAIN.COM
> kinit: Client 'DOMAINkacper_wirski at AD.MYDOMAIN.COM' not found in 
> Kerberos database while getting initial credentials
>
>
> but then when I do:
>
> [DOMAIN\kacper_wirski at vs-files ~]$ kinit kacper_wirski -V
> Using default cache: /tmp/krb5cc_101003
> Using principal: kacper_wirski at AD.MYDOMAIN.COM
> Password for kacper_wirski at AD.MYDOMAIN.COM:
> Warning: Your password will expire in 15 days on Thu 16 Nov 2017 
> 01:50:48 PM CET
> Authenticated to Kerberos v5
>
>
> and after this, user DOMAIN\kacper_wirski can do "kinit", and it 
> correctly defaults to principal "kacper_wirski at AD.MYDOMAIN.COM":
>
> [DOMAIN\kacper_wirski at vs-files ~]$ kinit -V
> Using principal: kacper_wirski at AD.MYDOMAIN.COM
> Password for kacper_wirski at AD.MYDOMAIN.COM:
>
>
> I don't know what gives. After full reboot it still works for "this" 
> user. When I log as DOMAIN\someotheruser it behaves exactly the same 
> (first adds DOMAIN prefix, then when once ticket is obtained 
> correctly, it seems to work...)
>
> kerberos ssh authentication (windows via putty to centos with samba 4) 
> works perfectly:
>
> Nov 01 12:21:29 vs-files.ad.mydomain.com sshd[1024]: Authorized to 
> DOMAIN\\kacper_wirski, krb5 principal kacper_wirski at AD.MYDOMAIN.COM 
> (ssh_gssapi_krb5_cmdok)
> Nov 01 12:21:29 vs-files.ad.mydomain.com sshd[1024]: 
> pam_winbind(sshd:account): user 'DOMAIN\kacper_wirski' granted access
> Nov 01 12:21:29 vs-files.ad.mydomain.com sshd[1024]: Accepted 
> gssapi-with-mic for DOMAIN\\kacper_wirski from 192.168.1.32 port 55825 ssh
>
> All file shares hosted by samba are correctly available to windows 
> clients.
>
> First of all:
>
> On test box I'm using samba 4.6.9 compiled from source.
>
> configure was run with simple --with-systemd --without-ad-dc
>
> //etc/resolv.conf:/
>
> //
>
> /# Generated by NetworkManager//
> //search ad.mydomain.com//
> //nameserver 192.168.1.5//
> //nameserver 192.168.1.6//
> //nameserver 192.168.1.7/
>
> all three IP's are DC's with DNS all work correctly
>
> //etc/hostname//
> //vs-files.ad.mydomain.com/
>
> //etc/hosts//
> //192.168.1.13 vs-files.ad.mydomain.com vs-files//
> //127.0.0.1   localhost localhost.localdomain localhost4 
> localhost4.localdomain4//
> //::1         localhost localhost.localdomain localhost6 
> localhost6.localdomain6/
>
> //etc/krb5.conf//
> //[libdefaults]//
> //    default_realm = AD.MYDOMAIN.COM//
> //    dns_lookup_realm = true//
> //    dns_lookup_kdc = true//
> ////
> //[realms]//
> //    AD.MYDOMAIN.COM = {//
> //        auth_to_local = RULE:[1:MYDOMAIN\$1]//
> //        }/
>
> The above rule is taken directly from the linked samba wiki guide, and 
> it really works (without it I won't login with kerberos ticket, unless 
> I drop "DOMAIN\" part using "winbind use default domain = yes".
>
> samba also auto-created it's own krb5.conf.DOMAIN file during net ads 
> join (in /usr/local/samba/var/lock/smb_krb5/
> /[libdefaults]//
> //        default_realm = AD.MYDOMAIN.COM//
> //        default_etypes = aes256-cts-hmac-sha1-96 
> aes128-cts-hmac-sha1-96 arcfour-hmac-md5 des-cbc-crc des-cbc-md5//
> //        dns_lookup_realm = false//
> //
> //[realms]//
> //        AD.MYDOMAIN.COM = {//
> //                kdc = 192.168.1.5//
> //                kdc = 192.168.1.6//
> //                kdc = 192.168.1.7//
> //        }/
>
>
> /etc/nsswitch.conf
> /passwd: files winbind//
> //shadow: files//
> //group: files winbind/
>
> And last but not least:
>
> /usr/local/samba/etc/smb.conf (i compiled from source, so all samba 
> files reside in /usr/local/samba/...)
> [global]
> /        security = ADS//
> //        netbios name = VS-FILES//
> //        workgroup = DOMAIN//
> //        realm = AD.MYDOMAIN.COM//
> //        log file = /var/log/samba/%m.log//
> //        log level = 5//
> //
> //   idmap config *:backend = tdb//
> //   idmap config * : range = 1000-2000//
> //   idmap config DOMAIN:backend = rid//
> //   idmap config DOMAIN:range = 100000-110000//
> //
> //        vfs objects = acl_xattr//
> //        map acl inherit = yes//
> //        store dos attributes = yes//
> //        template homedir = /home/%U@%D//
> //        template shell = /bin/bash//
> //        winbind enum groups = no//
> //        winbind enum users = no//
> //        kerberos method = secrets and keytab//
> //        winbind refresh tickets = yes//
> //        winbind use default domain = no//
> //        winbind offline logon = yes/
>
> Example output, when being logged as DOMAIN\kacper_wirski (login was 
> using kerberos, as shown in log, no password was required):
> [DOMAIN\kacper_wirski at vs-files ~]$ whoami
> DOMAIN\kacper_wirski
> [DOMAIN\kacper_wirski at vs-files ~]$ id
> uid=101003(DOMAIN\kacper_wirski) gid=100513(DOMAIN\domain users) 
> groups=100513(DOMAIN\domain users)... and some other groups from domain
>
> but then:
> [DOMAIN\kacper_wirski at vs-files ~]$ kinit -V
> Using default cache: /tmp/krb5cc_101003
> Using principal: DOMAINkacper_wirski at AD.MYDOMAIN.COM
> kinit: Client 'DOMAINkacper_wirski at AD.MYDOMAIN.COM' not found in 
> Kerberos database while getting initial credentials
>
> if do:
>
> [DOMAIN\kacper_wirski at vs-files ~]$ kinit kacper_wirski -V
> Using default cache: /tmp/krb5cc_101003
> Using principal: kacper_wirski at AD.MYDOMAIN.COM
> Password for kacper_wirski at AD.MYDOMAIN.COM:
> Warning: Your password will expire in 15 days on Thu 16 Nov 2017 
> 01:50:48 PM CET
> Authenticated to Kerberos v5
>
> then:
> [DOMAIN\kacper_wirski at vs-files ~]$ klist
> Ticket cache: FILE:/tmp/krb5cc_101003
> Default principal: kacper_wirski at AD.MYDOMAIN.COM
>
> Valid starting       Expires              Service principal
> 11/01/2017 12:32:36  11/01/2017 22:32:36 
> krbtgt/AD.MYDOMAIN.COM at AD.MYDOMAIN.COM
>         renew until 11/02/2017 12:32:31
>
> commands like:
> wbinfo -u etc. everything works, except for the "default principal" 
> used when doing kinit.
>
>
>
>
> Please help me understand, where else to look?
>
> Could the RULE in krb5.conf be causing all this? I removed it, 
> restarted whole machine, but it didn't change much.
>
> W dniu 2017-10-31 o 23:20, Rowland Penny pisze:
>> On Tue, 31 Oct 2017 22:46:53 +0100
>> Kacper Wirski via samba<samba at lists.samba.org>  wrote:
>>
>>> Hello,
>>>
>>> I'm setting up AD user logins for centos 7.4 box. I've almost managed
>>> to do everything the way I want and the way I think it should be, but
>>> I'm missing last piece:
>>>
>>>     For ssh access I read parts of the
>>> https://wiki.samba.org/index.php/OpenSSH_Single_sign-on
>>>
>>> Most docs recommend using setting in smb.conf:
>>> winbind use default domain = no
>>>
>>> that means that all domain users have DOMAIN\ prefix attached. As per
>>> the aforementioned wiki documet I made the workaround for
>>> authentication to krb5.conf, and it works OK.
>>>
>>> What isn't working is "kinit" as-is for logged in AD user. To be more
>>> precise: it works if I specify explicitly username
>>> kinit myusername
>>> or
>>> kinitmysusername at MY.DOMAIN.COM
>>> It works as expected (asks for password and grants ticket)
>>>
>>>    otherwise plain "kinit" uses by default posix username, which in
>>> this case is DOMAIN\myusername, so it looks for:
>>> DOMAINmyusername at MY.DOMAIN.COM  and fails with no principle found in
>>> database (and rightly so), because obviously it should use
>>> myusername at MY.DOMAIN.COM.
>>>
>>> I know it's not strictly samba related, and I could simply change
>>> winbind use default domain = yes
>>> as a workaround, this way everything works as expected, except that
>>> in all docs it's described as not recommended setup, because of
>>> possible confusion which user is from DOMAIN and which is local, and
>>> of course when multiple domains come into play.
>>>
>>> So maybe someone knows of a valid workaorund, how to force kinit to
>>> automatically remove/strip DOMAIN prefix from e.g.
>>> DOMAINmyusername at MY.DOMAIN.COM  and change it into
>>> myusername at MY.DOMAIN.COM? My understanding is that krb5.conf
>>> "auth_to_local" works the other way around, so it takes valid
>>> principal, and rewrites it so that it matches posix user and won't
>>> work in this case,as it's the other way round (posix user has to be
>>> translated into valid principal).
>>>
>>> My environment is:
>>> centos 7.4 OS
>>> samba 4.5.x is the AD DC
>>> samba 4.6.9 is domain member server and all tests are done on this
>>> machine.
>>>
>>> As i said, kerberos overall works fine, and it's not strictly samba
>>> issue, but the issue is because of samba configuration and added
>>> DOMAIN prefix.
>>>
>>> Any help/input/comments are appreciated.
>>>
>>> Regards, Kacper
>>>
>>>
>> You have something set up incorrectly, if I log into a Unix domain
>> member and run 'kinit', it works:
>>
>> rowland at devstation:~$ whoami
>> SAMDOM\rowland
>> rowland at devstation:~$ kinit
>> Password forrowland at SAMDOM.EXAMPLE.COM:
>> rowland at devstation:~$
>>
>> It also works on a DC.
>>
>> Can you post the following files:
>> /etc/resolv.conf
>> /etc/hosts
>> /etc/hostname
>> /etc/krb5.conf
>> /etc/samba/smb.conf
>>
>> Rowland
>>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Wolny od wirusów. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus