Connecting to Active Directory (possibly with winbind)

Question

I'm trying to figure out how to integrate Linux environment authentication system to Windows server 2012, and I found a way using winbind.

I've searched Google and there are several pages that introduce how to do it from synchronizing the time to configuring some config files.

I set the hostname and hosts in Linux such as following.

[/etc/hosts]
192.168.XXX.XX1 test1.example.com example ## Windows IP
192.168.XXX.XX2 test1 ## Linux IP

[/etc/hostname]
test1

I set up an Active Directory which has the following properties, and there are two accounts.

Computer name : TEST1
Domain        : example.com
Account1      : Administrator
Account2      : tester1

So, I set the Linux environment DNS to AD's IP address. Can check the info in the "resolv.conf".

[root ~]# nslookup example.com
Server:     192.168.xxx.xx1
Address:    192.168.xxx.xx1#53

Name:   example.com
Address: 192.168.xxx.xxx

In "nsswitch.conf", I added the 'winbind' word only next to 'files'.

passwd:     files winbind
shadow:     files sss winbind
group:      files winbind

In "krb5.conf", I changed the lookup part and default realm.

[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
default_realm = EXAMPLE.COM
[realms]
DOMAIN.COM = {
  kdc = example.com
  admin_server = example.com
}
[domain_realm]
.domain.com = EXAMPLE.COM
domain.com = EXAMPLE.COM

And finally, I set up smb.conf. However, there are lots of different way to set this up, so I'm not sure. Just selected one of the Google pages.

When I tried to connect to Windows Server with "administrator" id, it shows the following error:

[root ~]# net ads join -U Administrator
gse_get_client_auth_token: gss_init_sec_context failed with [Unspecified GSS failure.  Minor code may provide more information: Message stream modified](2529638953)
kinit succeeded but ads_sasl_spnego_gensec_bind(KRB5) failed for ldap/test1.example.com with user[Administrator] realm[EXAMPLE.COM]: The attempted logon is invalid. This is either due to a bad username or authentication information.
Failed to join domain: failed to connect to AD: The attempted logon is invalid. This is either due to a bad username or authentication information.

I'm stuck in this step, and I can't find the way how to solve it in Google. Do I need to edit some files in /etc/pam.d?

After use the tool 'testparm' about smb.conf, finally I can't find any problems, but now it shows the following message when I use "net ads testjoin".

ads_connect: No logon servers are currently available to service the logon request.

Solution

Undo all of your changes and delete the computer account from AD. Remove the winbind package.

Install a suitable selection of packages. On Debian-based systems you can use apt-get install samba smbclient sssd realmd dnsutils policykit-1 packagekit sssd-tools sssd libnss-sss libpam-sss adcli.

Don't worry at this point if sssd fails to start. It needs to be configured with the realm command, which we're going to address in a moment.

Make sure your local Linux-based system has your DC at its DNS server. Do not add any additional DNS server unless it is part of your Active Directory environment. If you simply edit /etc/resolv.conf and ignore the "do not edit this file" warning, your changes will probably get overwritten. At this point your system will fail to authenticate anyone and may even eventually fall off the domain. (Users tend to get unhappy at this point.)

Make sure your local time matches the time in Active Directory, since Kerberos won't work with a skew of greater than about 5 minutes (300 seconds).

For your local domain contoso.com run these three commands as root:

domain=contoso.com          # The FQDN itself. Not machine.FQDN
realm discover "$domain"    # If this fails, stop and recheck everything
realm join "$domain"        # [--user <ad_username>] [--computer-ou <ou>]

If you need to provide an AD account name for the realm join, do so with realm join --user <ad_username> "$domain", where <ad_username> represents an unqualified sAMAccountName. Your own AD account should work for a minimum of ten clients even if it is not a domain administrator, although administrator is a useful choice if you know its password. The --computer-ou option allows you to specify the initial OU for the account. Leave this blank unless you know its correct value (don't guess it).

Fix up the sssd.conf file. The ad_hostname is necessary for some versions to work around a bug. The LDAP group nesting level allows sssd to handle membership of nested groups.

sed -i "/^ad_domain /s/$/\nad_hostname = $(hostname).$domain/" /etc/sssd/sssd.conf
( echo; echo 'ldap_group_nesting_level = 5'; echo 'ldap_use_tokengroups = false' ) >>/etc/sssd/sssd.conf
service sssd restart

Comments

[Michael Mrozek]

Conversation has been moved to chat.