Authentication of GNU / Linux file servers in an AD-based Windows domain. Part 2
1. Configuration files.
We will only configure access to the GNU / Linux server using Samba. User authorization will remain local using / etc / passwd.
We will assign a static IP address to our new server. Let it be 192.168.7.9.
First you need to check which server we use as DNS. It must be a domain controller in our network. Our server address is defined as 192.168.7.2. Edit the file /etc/resolv.conf. It should look like this:
search lab.local
nameserver 192.168.7.2
Check if everything works:
#host 192.168.7.2
2.7.168.192.in-addr.arpa domain name pointer lab-dc1.lab.local.
#
Naturally, in your case the names will be different. Be sure to make a DNS entry in the lab.local domain that references our new server. Recording in DNS does not mean that our GNU / Linux server is included in the domain. Check:
linux-test:~ # host 192.168.7.9
9.7.168.192.in-addr.arpa domain name pointer test-linux.lab.local.
linux-test:~ # host test-linux
test-linux.lab.local has address 192.168.7.9
linux-test:~ #
To work correctly in a Windows domain, several services are required: Kerberos, LDAP, and Samba. In the general case, only Samba configuration is required; configuring other services is optional. But it will be better if we set them up - they may come in handy in the future.
Kerberos is easy to configure - through a single /etc/krb5.conf file. The main parameters are REALM, pointing to our domain and the address of the Kerberos server is the address of the domain controller. The file /etc/krb5.conf looks something like this:
linux-test:~ # more /etc/krb5.conf
[libdefaults]
default_realm = LAB.LOCAL
clockskew = 300
# default_realm = EXAMPLE.COM
[realms]
LAB.LOCAL = {
kdc = 192.168.7.2
default_domain = lab.local
admin_server = 192.168.7.2
}
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON
[domain_realm]
.lab.local = LAB.LOCAL
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
minimum_uid = 1
external = sshd
use_shmem = sshd
clockskew = 300
}
The [libdefaults] section points to the default domain. We have it LAB.LOCAL. Next, in the [realms] section, the parameters for LAB.LOCAL are specified - the domain name and address of the Kerberos server. In our case, the domain controller acts as the Kerbeors server. In the [logging] section, the location of the log files is indicated. These files come in handy for troubleshooting if something goes wrong.
Check the operation of Kerberos:
linux-test:~ # kinit Administrator@LAB.LOCAL
Password for Administrator@LAB.LOCAL:
linux-test:~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@LAB.LOCAL
Valid starting Expires Service principal
04/05/12 11:22:23 04/05/12 21:22:35 krbtgt/LAB.LOCAL@LAB.LOCAL
renew until 04/06/12 11:22:23
linux-test:~ #
The kinit command receives a ticket from the server, and klist shows the received tickets from the server. Running kinit is optional, but do you need to check Kerberos somehow?
Configuring LDAP is also optional - Samba itself will build the necessary files and make the necessary queries. But LDAP may come in handy later on. The OpenLDAP configuration is stored in the /etc/openldap/ldap.conf file. Please note that there may be two ldap.conf files on the system. They have different purposes and even a slightly different syntax. The / etc / openldap directory contains the ldap.conf file for OpenLDAP (and for Samba), and the /etc/ldap.conf file contains the configuration for resolving names through LDAP (for nss_ldap). We will return to the /etc/ldap.conf file in other articles, now we will configure /etc/openldap/ldap.conf
linux-test:~ # cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
uri ldap://192.168.7.2
base DC=lab,DC=local
linux-test:~ #
As you can see, everything is very simple - you need to specify the LDAP server URI (this is our domain controller) and the base for the search.
Now let's move on to the hardest part - setting up Samba.
Samba includes 3 daemons - smbd, nmbd and winbind. They all take the settings from the /etc/samba/smb.conf file.
Smbd is responsible for client access to the SMB / CIFS service (this is actually the Samba server). Nmbd is a name resolution service for Netbios. Winbind is a name resolution service (for both computers and users) through Windows Domain Services.
In many manuals, you may find mention that in addition to Samba, you also need to configure winbind, the service responsible for the relationship between GNU / Linux and the Windows domain controller. In the particular case when you need to configure only Samba, winbind settings can be omitted. Winbind provides authorization in the Windows domain for a variety of services, providing an interface between the PAM modules and the Windows domain controller. With winbind not working, Samba remains operational. But by setting up winbind, we make it possible to further expand our server by adding various services that are authorized through the domain controller.
We will make the simplest server by opening all users access to a shared file directory and to the users home directory. We will talk more about setting up access to the Samba server in other articles.
In the /etc/samba/smb.conf file, we must specify the following lines:
[global]
workgroup = LAB
passdb backend = ldapsam:ldap://192.168.7.2
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
logon path = \\%L\profiles\.msprofile
logon home = \\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = Yes
Here we indicate the abbreviated name of our domain (LAB) and the place where the passwords are stored - the passdb backend parameter, which indicates that the passwords are on the LDAP server, which is the domain controller. By the way, you can specify several servers by listing them with a space. This is useful if we have multiple domain controllers. The usershare allow guests = Yes line allows users to control access to their folders by opening them for guests. The remaining lines relate to print management and the registration process. In our case, they are optional and migrated from the configuration file of the Samba distribution.
Continue editing the [global] section of smb.conf.
domain logons = No
domain master = No
security = ADS
encrypt passwords = yes
The domain logons and domain master strings allow Samba to be used as a domain controller. This is not our case, and therefore No.
The string security = ADS is key. Thus, we indicate to Samba that the server is a member of the Windows domain and AD is responsible for authorization. The string encrypt passwords = yes means that encrypted passwords are used.
We continue to edit the same [global] section.
ldap admin dn = Administrator@lab.local
ldap delete dn = No
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=Computers
ldap passwd sync = Yes
ldap ssl = No
ldap suffix = DC=lab,DC=local
ldap timeout = 5
ldap user suffix = ou=Users
These lines relate to managing the connection to the LDAP server. Note that the administrator DN record form has the user @ domain form - it must match what we specified when testing Kerberos. The remaining lines indicate the suffixes of various locations in AD.
The following lines already apply to Kerberos:
realm = LAB.LOCAL
template homedir = /home/%D/%U
winbind refresh tickets = yes
kerberos method = system keytab
Here we specify the REALM and authentication method in Kerberos.
Now the lines that relate to winbind configuration:
winbind separator = /
winbind enum users = yes
winbind enum groups = yes
winbind nested groups = yes
winbind use default domain = No
winbind nss info = rfc2307
winbind offline logon = yes
Various parameters of Winbind operation are indicated here - a form for separating domain and user names, permission for winbind to list user and group names, permission for offline authentication, etc. These settings are recommended by Samba developers.
The global settings section is completed. Please note that we do not have the password server and idmap backend lines that can be found in other manuals. Samba must figure out where the passwords come from.
Let's move on to setting up directories. Everything is simple here:
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
available = Yes
[profiles]
comment = Network Profiles Service
path = %H
read only = No
store dos attributes = Yes
create mask = 0600
directory mask = 0700
[users]
comment = All users
path = /home
read only = No
inherit acls = Yes
veto files = /aquota.user/groups/shares/
[groups]
comment = All groups
path = /home/groups
read only = No
inherit acls = Yes
[SRV]
comment = Common files
path = /local
write list = Administrator
guest ok = Yes
hosts allow = 192.168.7.
To the standard list of shared directories distributed with the Samba distribution, we added only the [SRV] section - the public directory.
The configuration of all necessary files is completed, and we begin to check the operability of our server.
2. Health check.
Here we will check the correctness of our settings and include our new server in the Windows domain. First, check the correctness of the Samba configuration:
l
inux-test:~ # testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[homes]"
Processing section "[profiles]"
Processing section "[users]"
Processing section "[groups]"
Processing section "[SRV]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
As you can see, we do not have any serious warnings and configuration errors.
Now start the smbd, nmbd and winbindd daemons in turn. We do this through the files /etc/init.d/smb, /etc/init.d/nmb and /etc/init.d/winbind. You can do this manually as well, which may be useful for obtaining various additional information. How to do this can be found in the built-in manuals (man) on smbd, nmbd and winbindd.
Check the status of our domain and our server in the domain. Domain status can be obtained with net ads info command
linux-test:~ # net ads info
LDAP server: 192.168.7.2
LDAP server name: LAB-DC1.lab.local
Realm: LAB.LOCAL
Bind Path: dc=LAB,dc=LOCAL
LDAP port: 389
Server time: Thu, 05 Apr 2012 13:03:47 MSK
KDC server: 192.168.7.2
Server time offset: 4
linux-test:~ #
Apparently, everything is in order. If any parameters displayed by the command do not match our plan, you need to look for the reason. Now check the status of our server in the domain:
l
inux-test:~ # net ads status -U Administrator
Enter Administrator's password:
No machine account for 'LINUX-TEST' found
linux-test:~ #
It follows that our server is not included in the domain. A request to the domain controller is made on behalf of the administrator, and the password must be specified from the Windows domain administrator account.
Now we must include our server in the domain:
l
inux-test:~ # net ads join -U Administrator
Enter Administrator's password:
Using short domain name -- LAB
Joined 'LINUX-TEST' to realm 'lab.local'
DNS Update for linux-test.lab.local failed: ERROR_DNS_UPDATE_FAILED
DNS update failed!
linux-test:~ #
So, our new server is included in the domain, as evidenced by the lines:
Using short domain name -- LAB
Joined 'LINUX-TEST' to realm 'lab.local'
Dynamic change of DNS did not pass with us. This is not scary, because it was not planned. Now it is recommended to restart all our processes - smbd, nmbd and winbindd. Note that after a restart, a few minutes should pass before further checks.
Check the status of our server in the domain:
linux-test:~ # net ads status -U Administrator
Enter Administrator's password:
In response, we get a printout of the status of our new server in the domain. Various AD fields related to our server will be listed there. We will also see our GNU / Linux server on the Computers tab, by running the AD admin tool on the domain controller.
You can check the list of domain users:
l
inux-test:~ # net ads user -U Administrator
Enter Administrator's password:
Administrator
Guest
krbtgt
usertest
linux-test:~ #
And check the operation of winbind:
linux-test:~ # wbinfo -t
checking the trust secret for domain LAB via RPC calls succeeded
linux-test:~ #
And we get a list of users in the domain:
l
inux-test:~ # wbinfo -u
LAB/administrator
LAB/guest
LAB/krbtgt
LAB/usertest
linux-test:~ #
You can check the status of the domain through wbinfo:
l
inux-test:~ # wbinfo -D LAB
Name : LAB
Alt_Name : lab.local
SID : S-1-5-21-3914562201-450990341-53424453
Active Directory : Yes
Native : Yes
Primary : Yes
linux-test:~ # wbinfo -P
checking the NETLOGON dc connection succeeded
linux-test:~ #
Everything is good. Now the most important check is to try to open the directories on our new server using a workstation running Windows 7. Our workstation is included in the domain. We should see our new server on the Network tab of a Windows browser, either by specifying a name or IP address:
Now we can proceed to further procedures for setting up our server. In the future, we will consider some of the nuances of the described process depending on the GNU / Linux distribution and consider in more detail the setting of access rights to the Samba server.
The work was performed on the basis of the Information and Computing Center MPEI.