Winbind, Kerberos ticket, machine principal

M

mletzgus

I have a problem with winbind because something is working - and I don't know why. *G*

It's FreeBSD9 with Samba 3.6.7, joined to Active Directory (security=ADS), no(!) special krb5.conf file present, everything is working fine.

But every time I start up winbindd a kerberos ticket (/tmp/krb5cc_0) is created, if I stop winbindd the file is removed:

Code: 
[root@myhost ~/scripts]# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: myhost$@mydomain

  Issued           Expires          Principal
Oct 11 16:16:25  Oct 12 02:16:25  krbtgt/mydomain.DE@mydomain
Oct 11 16:16:25  Oct 12 02:16:25  ldap/dc2.mydomain.DE@mydomain

My Problem is: I have never created a ticket using kinit, I just joined the domain using

Code: 
net ads join -U domainadminusername

Why does winbindd create this _0 ticket? I've never sees this before on any other of my machines...

If I try to do this manually using

Code: 
kinit domainadminusername@mydomain

the result is:
Code: 
[root@myhost ~/scripts]# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: domainadminusername@mydomain


The principal is "domainadminusername" - but not "myhost$"?

What is the reason for this automagically created ticket and how can I forbid winbindd to do this?

Best regards,
Michael


smb.conf:

Code: 
[global]

    netbios name = myhost
    netbios aliases = myhost-alias

    server string = MyServer

    bind interfaces only = yes
    interfaces = 127.0.0.0/8 em0
    socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY

#    use sendfile = yes
#    aio read size = 16384

    realm = mydomain.de
    workgroup = mydomain
    security = ads

    domain master = no
    local master = no
    preferred master = no

    name resolve order = host wins bcast

    allow trusted domains = No

    winbind use default domain = no
    winbind refresh tickets = yes

    winbind offline logon = yes
    winbind reconnect delay = 30

    winbind cache time = 3600

    winbind enum users = no
    winbind enum groups = yes

    winbind expand groups = 2
    winbind nested groups = yes

    idmap config *: backend = rid
    idmap config *: range = 100000-9000000

    idmap config AD: backend = rid
    idmap config AD: range = 100000-9000000

    template shell = /bin/bash
    template homedir = /home/%D/%U


    time server = yes

    unix charset = utf8

    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes

    syslog only = no

    min protocol = NT1

    create mask = 0600
    directory mask = 0700

    log level = 1

    unix extensions = no
 
I haven't played with samba and ADS, but I have some experience with Kerberos. In your situation, it seems that in order for your fileserver to communicate with the rest of the servers of the same AD domain, it needs to established some sort of trust. And since AD uses Kerberos, then your domain of trust is established via Kerberos (through your realm MYDOMAIN).

Now, the credential cache created in /tmp by your process (most probably winbindd, as you say) -which runs as root, hence its name krb5cc_0- is used to give your process the privileges of the principal 'myhost$@MYDOMAIN' with respect to MYDOMAIN. Moreover, from your credential cache file, we can see that your server exchanges information with your ldap server principal: ldap/dc2.mydomain.DE@MYDOMAIN.

So, you need to find out how your process obtains a ticket for principal myhost$@mydomain. This is, usually, achieved by reading /etc/krb5.keytab. If this file is not present, then check your samba configuration files to see where your winbindd process reads its keytab, or just run ktrace(1) on winbindd (you need to run it manually) and see which files it reads. One of them is the keytab which gives your process these privileges.

In order to see the contents of your keytab file you can use this command:

# ktutil -k /path/to/keytab list
 
Ah,

and as far as kerberos and /etc/krb.conf is concerned, all information needed for your server to find kerberos information about your realm is located in SRV records in your AD's DNS server configuration. This is Microsoft's AD default setup.
 
Hi mamalos,

thanks for your suggestions. I just notified another differences: winbind stores either krb5cc_0 or it's own secrets.tdb. But what's the reason for that different behavior?

In both cases there is no /etc/krb5.keytab nor any /etc/krb5.conf - just the "naked" winbind. winbind successfully retrieves all infos about DCs ans encryption and stores it in its own krb5.conf.
 
If the principal winbind connects as is a host principal (it can't be shown in your comments because you've changed the original), then I suppose there must be a keytab file somewhere. It is not common practice to put a password for a host principal, not that it can't be done. Try ktrace(1) to find it, if you're concerned.

As far as /etc/krb5.conf is concerned, as I explained to you before, if DNS is set correctly (which is mandatory for MS-AD to work) you don't need it, provided you use the correct DNS servers in your /etc/resolv.conf.

On the other hand, I shouldn't play the smart guy, since I haven't used such a setup before...:-P
 
You must log in or register to reply here.
Back
Top