Taylor Hammerling's picture

I am having an issue with TKL domain controller 14.1

When I install the appliance and allow it to run it's security auto update, I end up with this

Looking up IPv6 addresses
No IPv6 address will be assigned
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Adding DomainDN: DC=mydomain,DC=com
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Modifying display specifiers
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=mydomain,DC=com
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
A Kerberos configuration suitable for Samba 4 has been generated at /var/lib/samba/private/krb5.conf
Setting up fake yp server settings
Once the above files are installed, your Samba4 server will be ready to use
Server Role:           active directory domain controller
Hostname:              dc1
NetBIOS Domain:        MYDOMAIN
DNS Domain:            mydomain.com
DOMAIN SID:            S-1-5-21-859147655-2648909413-54802912
Expiry for user 'administrator' disabled.
kinit: Cannot find KDC for realm "MYDOMAIN.COM" while getting initial credentials
Traceback (most recent call last):
  File "/usr/lib/inithooks/bin/domain-controller.py", line 123, in <module>
  File "/usr/lib/inithooks/bin/domain-controller.py", line 118, in main
    system('echo {ADMIN_PASSWORD} | kinit {ADMIN_USER}@{REALM}'.format(ADMIN_PASSWORD=admin_password, ADMIN_USER=ADMIN_USER, REALM=realm.upper()))
  File "/usr/lib/python2.7/dist-packages/executil.py", line 56, in system
    raise ExecError(command, exitcode)
executil.ExecError: non-zero exitcode (1) for command: echo %MYPASSWORD% | kinit administrator@MYDOMAIN.COM
root@dc1 ~#


If I don't allow the appliance to run it's security update, the domain-controler.py script runs just fine.


Any help you can provide me would be greatly appreciated!


Taylor Hammerling

Taylor Hammerling's picture

I should note that the output in the formatted box above comes from the domain-controler.py script.

Taylor Hammerling's picture

Ok, I have done more troubleshooting, getting close to resolution here, but would love some insight from some of the people who have more knowledge about samba, kerberos and winbindd.

I found that the security update of samba from version 
is the update which is breaking a clean install of TKL 14.1 AD.

prior to performing the security update the file /usr/sbin/winbindd did not exist, but it didn't matter.  I was able to run the 
without any error.

After performing the security update, running the domain-controller.py script netted me the errors in my initial post.
I changed the samba log level to 3 and ran "samba -i" and noticed the following error

/usr/sbin/winbindd: Failed to exec child - No such file or directory

That gave me the idea to install winbind by running
apt-get install winbind

After installing winbind, I re-ran "samba -i" and it actually started properly.
I then re-ran the domain-controller.py script, and it finished properly!!!

So here is my question,

Why would samba version 4.1.17+dfsg-2+deb8u2 work without winbindd but version 4.2.14+dfsg-0+deb8u2 won't?

Thanks in advance for any help you can provide,


Jeremy Davis's picture

Looks like you have it sorted. Thanks for reporting and posting back with a fix.

To answer your question, TBH I'm not 100% sure. Bumping versions in a security update is very rare in Debian. Mostly, because it can introduce issues like this.

My guess is that developing a backported security patch for Samba 4.1 to fix the issue was too hard. So they instead packaged a newer version (which either didn't have the issue, or perhaps just had a patch available). I couldn't find any specific info on why winbind is required. My guess is that some additional functionality was needed (which is provided by winbind) to resolve/workaround the security issue.

FWIW I am currently working on a new release so we will be updating all the appliances soon. That won't affect your server, but it will mean that any new servers launched will include winbind and will work out of the box... Thanks again! :)

Add new comment