You are here

Adding an Ubuntu computer to a Windows domain


Introduction

Often there is a need to enter a Linux machine into an existing Windows domain. For example, to make a file server using Samba. To do this is very simple, for this you will need a Kerberos, Samba, and Winbind client.

Before installation it is desirable to update:

sudo aptitude update
sudo aptitude upgrade

You can install all this stuff with the command:

sudo aptitude install krb5-user samba winbind 

You may also need to install the following libraries:

sudo aptitude install libpam-krb5 libpam-winbind libnss-winbind

Or, if you are using Ubuntu Desktop, the same packages can be delivered through the Synaptic package manager.

Next, you need to configure all of the above tools to work with your domain. Let's say you want to enter the domain DOMAIN.COM, the domain controller of which is the dc.domain.com server with the IP address 192.168.0.1. The same server is also the primary DNS server of the domain. In addition, let's say you have a second domain controller, it's also DNS - dc2.domain.com with IP 192.168.0.2. Your computer will be called smbsrv01.

Configuring DNS

To begin, you need to change the DNS settings on your machine by registering the domain controller as the DNS server and the domain as the search domain.

If you have a static IP address, you can do it in Ubuntu Desktop via Network Manager, in Ubuntu Server you need to change the contents of the /etc/resolv.conf file to something like this:

domain domain.com
search domain.com
nameserver 192.168.0.1
nameserver 192.168.0.2

In modern distributions the resolv.conf file is created automatically and you do not need to edit it manually. To obtain the desired result, you need to add the necessary changes to the file: /etc/resolvconf/resolv.conf.d/head The data that will be added to it will be automatically inserted into the file /etc/resolv.conf

If the IP address is dynamic and assigned by the DHCP server, then after resolv.conf reboot, an "incorrect" resolv.conf can be formed, for example, there is only one nameserver 192.168.0.1 and domain and search are not specified. You need to edit /etc/dhcp/dhclient.conf. In order for domain and search records to appear, you need to remove the comment before the string supersede domain-name, and enter your domain:

supersede domain-name "domain.com";

To add another nameserver, you need to remove the comment before prepend domain-name-servers and specify the ip server:

prepend domain-name-servers 192.168.0.2;

To apply the changes, it remains to restart the service:

/etc/init.d/networking restart

Now make sure that you have specified the correct computer name in the /etc/ hostname file:

smbsrv01

In addition, you need to edit the /etc/hosts file so that it has an entry with the fully qualified domain name of the computer and necessarily a short host name that references one of the internal IPs:

# This computer names
127.0.0.1	localhost
127.0.1.1	smbsrv01.domain.com	smbsrv01

Immediately need to check that our domain controller, on a short and full name, normally pings, so that in the future we do not receive errors that the domain controller is not found:

ping dc
ping dc.domain.com

Not necessarily, but if you change something - restart the computer to apply the changes.

Configuring Time Synchronization

Next, you need to configure the time synchronization with the domain controller. If the difference is more than 5 minutes, we will not be able to get a sheet from Kerberos. For a one-time synchronization, you can use the command:

sudo net time set dc

If there is an exact time server on the network, then you can use it or any public one:

ntpdate ntp.mobatime.ru

Automatic synchronization is configured using ntpd, this daemon will periodically synchronize. To get started, you need to install:

sudo aptitude install ntp

Now fix the /etc/ntp.conf file, adding information about your time server to it:

# You do need to talk to an NTP server or two (or three).
server dc.domain.com

Then restart the ntpd daemon:

sudo /etc/init.d/ntp restart

Now it's time to configure the interaction directly with the domain.

Configuring Kerberos Authorization

НWe will use the Kerberos protocol to configure the authorization in the domain. You will need to modify the /etc/krb5.conf file. In general, it looks like this:

[libdefaults]
	default_realm = DOMAIN.COM
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
	v4_instance_resolve = false
	v4_name_convert = {
		host = {
			rcmd = host
			ftp = ftp
		}
		plain = {
			something = something-else
		}
	}
	fcc-mit-ticketflags = true

[realms]
	DOMAIN.COM = {
		kdc = dc
		kdc = dc2
		admin_server = dc
		default_domain = DOMAIN.COM
	}

[domain_realm]
	.domain.com = DOMAIN.COM
	domain.com = DOMAIN.COM
[login]
	krb4_convert = false
	krb4_get_tickets = false

You, of course, need to change domain.com to your domain and dc and dc2 to your domain controllers. By the way, you may need to write the full domain controller names dc.domain.com and dc2.domain.com. Since I have a DNS search domain, I do not need to do this.

Pay special attention to the domain name writing register - wherever the domain is written in uppercase, it must always be written in uppercase. Otherwise, in a magical way, nothing can be earned.

These are not all possible options for configuring Kerberos, only basic ones. However, they are usually sufficient.

Now it's time to check that we can log in to the domain. To do this, run the command

kinit [email protected]

Instead of username, it's natural to enter the name of an existing domain user.

The domain name must be written in capital letters!

If you have not received any errors - then you have set everything up correctly and the domain gives you the Kerberos ticket. By the way, some common mistakes are listed below.

To make sure that the ticket is received, you can run the command

klist

To delete all tickets (they generally do not need you) you can use the command

kdestroy

So, we'll assume that you've set up the authorization, it's time to set up a direct login to the domain, about this after a list of common kinit errors.

Common kinit errors

kinit(v5): Clock skew too great while getting initial credentials

This means that your computer is not synchronized with the time domain controller (see above).

kinit(v5): Preauthentication failed while getting initial credentials

You entered an incorrect password.

kinit(v5): KDC reply did not match expectations while getting initial credentials

The strangest mistake. Make sure that the name realm in krb5.conf, as well as the domain in the kinit command are entered in capital letters:

DOMAIN.COM = {
# ...
kinit [email protected]
kinit(v5): Client not found in Kerberos database while getting initial credentials

The specified user does not exist in the domain.

Configuring Samba and logging on to a domain

In order to enter the domain, you need to set the correct settings in the /etc/samba/smb.conf file. At this stage, you should only be interested in some of the options from the [global] section. Below is an example of part of the Samba configuration file with comments about the meaning of important parameters:

[global]
    # These two options need to be written in the uppercase register, and the workgroup without
    # The last section after the point, and realm - the full domain name
   workgroup = DOMAIN
   realm = DOMAIN.COM

   # These two options are responsible for the authorization via AD
   security = ADS
   encrypt passwords = true
   # Simply important
   dns proxy = no 
   socket options = TCP_NODELAY

   # If you do not want Samba to try to get on the leaderboard in a domain or working group,
    # Or even become a domain controller, then always prescribe these five options in this form
   domain master = no
   local master = no
   preferred master = no
   os level = 0
   domain logons = no

   # Disable printer support
   load printers = no
   show add printer wizard = no
   printcap name = /dev/null
   disable spoolss = yes

After you edit smb.conf, run the command

testparm

It will check your configuration for errors and give a summary about it:

# testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

As you can see, we have set the right parameters for our computer to become a member of the domain. Now it's time to try to enter the domain directly. To do this, enter the command:

net ads join -U username -D DOMAIN

And if successful, you will see something similar to:

# net ads join -U username -D DOMAIN
Enter username's password:
Using short domain name -- DOMAIN
Joined 'SMBSRV01' to realm 'domain.com'

The "net" command used

-U username%password: required parameter, instead of username, you must substitute the username with domain administrator rights, and specify a password.

-D DOMAIN: DOMAIN - actually the domain itself, the domain can not be specified, but it's better to do it all the time - it will not be worse.

-S win_domain_controller: win_domain_controller, you can not specify, but there are cases when the server does not automatically find the domain controller.

createcomputer=«OU/OU/…» : In AD, OU (Organizational Unit) is often used, there is OU = Office in the root of the domain, in it OU = Cabinet, so that you can immediately add it to the right one: sudo net ads join -U username createcomputer = "Office/Cabinet".

If there are no more messages, then everything is fine. Try to ping your computer by name from another member of the domain to make sure that everything in the domain is set up as it should.

You can also type the following command:

net ads testjoin

If everything is good, you can see:

#net ads testjoin
Join is OK

But sometimes after the message of joining to the domain an error is produced like:

DNS update failed!

This is not very good, and in this case it is recommended to read the DNS configuration section a little bit more and understand what you did wrong. After that, you need to remove the computer from the domain and try to enter it again. If you firmly believe that everything is configured correctly, but DNS is still not updated, then you can manually write a record for your computer to your DNS server and everything will work. Of course, if there are no other errors, and you have successfully entered the domain. However, it's better to understand why DNS is not updated automatically. This can be due not only to your computer, but also to the incorrect setting of AD.

Before you figure out why DNS is not updated, do not forget to restart your computer after entering the domain! It is possible that this will solve the problem.

If everything went smoothly, then congratulations, you have successfully entered the domain! You can look into AD and see for yourself. In addition, it would be nice to check that you can see the resources in the domain. To do this, install smbclient:

sudo aptitude install smbclient

Now you can view the resources of the domain computers. But for this you need to have a ticket kerberos, i.e. If we delete them, we get again through kinit (see above). Let's see what resources are provided to the network by the computer workstation:

smbclient -k -L workstation

You should see a list of shared resources on this computer.

Configuring Winbind

If you need to work with domain users, for example, to configure SMB-shares with access control, then you will need Winbind in addition to the Samba itself, a special daemon that will link the local user management system and Linux groups to the Active Directory server. Simply put, Winbind is needed if you want to see domain users on your computer with Ubuntu.

Winbind allows you to project all users and all AD groups to your Linux system, assigning them IDs from the specified range. In this way, you can assign users of the domain to the owners of folders and files on your computer and perform any other operations that are tied to users and groups.

To configure Winbind, the same /etc/samba/smb.conf file is used. Add the following lines to the [global] section:

    # Options for mapping domain users and virtual users in the system via Winbind.
    # Identity ranges for virtual users and groups.
   idmap uid = 10000 - 40000
   idmap gid = 10000 - 40000
   # These options should not be turned off.
   winbind enum groups = yes
   winbind enum users = yes
   # Use the default domain for user names. Without this option, the names of users and groups
    # Will be used with the domain, i.e. Instead of username - DOMAIN\username.
    # This is probably what you need, but it's usually easier to include this option.
   winbind use default domain = yes
   # If you want to allow the use of the command line for domain users, then
    # Add the following line, otherwise the shell will be called /bin/false
   template shell = /bin/bash
   # To automatically update the Kerberos ticket with the pam_winbind.so module, you need to add a line
   winbind refresh tickets = yes
Options:

idmap uid = 10000 - 40000

idmap gid = 10000 - 40000

In new versions of Samba are already outdated and when checking the config samba using testparm will be issued a warning:

WARNING: The «idmap uid» option is deprecated

WARNING: The «idmap gid» option is deprecated

To remove warnings, you need to replace these lines with new ones:

idmap config * : range = 10000-20000

idmap config * : backend = tdb

Now restart the Winbind and Samba daemon in the following order:

sudo /etc/init.d/winbind stop
sudo smbd restart
sudo /etc/init.d/winbind start 

Launch:

sudo testparm

See if there are any errors or warnings if you see:

«rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)»

You can fix this without rebooting:

ulimit -n 16384

To save after reboot, edit the /etc/security/limits.conf file

# Add lines to the end of the file:
*               -    nofile            16384
root            -    nofile            16384

After restarting, verify that Winbind has established a trust relationship with the AD command:

# wbinfo -t
checking the trust secret for domain DCN via RPC calls succeeded

And also, that Winbind saw users and groups from AD commands:

wbinfo -u
wbinfo -g

These two commands must provide a list of users and groups from the domain, respectively. Either with the DOMAIN prefix \ or without it, depending on what value you specified in the parameter "winbind use default domain" in smb.conf.

So, Winbind works, but it is not integrated into the system yet.

Adding Winbind as a user and group source

In order for your Ubuntu to work transparently with domain users, in particular, so that you can assign domain users to folder and file owners, you must tell Ubuntu to use Winbind as an additional source of information about users and groups.

To do this, change the two lines in the /etc/nsswitch.conf: file: information about users and groups.

passwd:         compat
group:          compat

Adding to the end winbind:

passwd:         compat winbind
group:          compat winbind

I also recommend bringing the files in /etc/nsswitch.conf to the form:

files:          dns mdns4_minimal[NotFoud=return] mdns4

ow check that Ubuntu asks Winbind for information about users and groups:

getent passwd
getent group 

The first command is to return all the contents of your /etc/passwd file, that is, your local users, plus the domain users with the ID from the range you specified in the smb.conf. The second should do the same for groups.

Now you can take any user of the domain and make it, for example, the owner of some file.

Authorization in Ubuntu through domain users

Despite the fact that all users of the domain are actually full users of the system (as you can see by completing the last two commands from the previous section), you can not go to anybody else under the system. To enable the authorization of domain users on a computer with Ubuntu, you must configure PAM to work with Winbind.

Online authorization

For Ubuntu 10.04 and higher, add just one line in the /etc/pam.d/common-session file, because PAM and so well copes with authorization:

session  optional  pam_mkhomedir.so skel=/etc/skel/ umask=0077

For Ubuntu 13.10, in order for the manual input field to appear, you must add a line from below in the /etc/lightdm/lightdm.conf/ directory below:

greeter-show-manual-login=true

For Ubuntu 9.10 and below, you will have to edit several files (but nobody forbids using this method in 10.04 - it also works):

The string sequence in the files matters!

/etc/pam.d/common-auth

auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth nullok try_first_pass
auth        sufficient    pam_winbind.so use_first_pass krb5_auth krb5_ccache_type=FILE
auth        required      pam_deny.so

/etc/pam.d/common-account

account     sufficient    pam_winbind.so
account     required      pam_unix.so

/etc/pam.d/common-session

session     optional      pam_mkhomedir.so skel=/etc/skel/ umask=0077
session     optional      pam_ck_connector.so nox11
session     required      pam_limits.so
session     required      pam_env.so
session     required      pam_unix.so

/etc/pam.d/common-password

password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    sufficient    pam_winbind.so
password    required      pam_deny.so

Finally, you need to migrate Winbind startup when the system boots after all other services (by default it starts with index 20). To do this, run the following command in the terminal:

sudo bash -c "for i in 2 3 4 5; do mv /etc/rc$i.d/S20winbind /etc/rc$i.d/S99winbind; done"

What is equivalent to starting for each level (in the example - 4) the commands:

mv /etc/rc4.d/S20winbind /etc/rc4.d/S99winbind
In some cases, winbind can have a different start level (for example, S02winbind). Therefore, first check the file names by typing "ls /etc/rc{2,3,4,5}.d/ | Grep winbind "(without quotes).

Done, all settings are complete. Reboot and try to log in with a domain user account.

Offline authorization

Often there is a situation when the domain controller is unavailable for various reasons - prevention, turning off the light or you brought the laptop home and want to work. In this case, for Winbind, you can configure the caching of domain user accounts. To do this, you need to do the following. Add the following lines to the [global] section of the /etc/samba/smb.conf file:

[global]
   # The possibility of offline authorization when the domain controller is inaccessible
   winbind offline logon = yes
   # The period of account caching, by default is 300 seconds
   winbind cache time = 300
   # An optional configuration, but eliminates tedious pauses, specify the domain controller dc,
   # You can also specify ip, but this is a bad tone
   password server = dc

Usually this is enough. If errors occur, you should create a file /etc/security/pam_winbind.conf with the following content:

Attention! When using tips below, you may experience a completely random "Authentication failed" error! Therefore, everything you do, you do at your own peril and risk!
#
# pam_winbind configuration file
#
# /etc/security/pam_winbind.conf
#
[global]
  # turn on debugging
  debug = no
  # request a cached login if possible
  # (needs "winbind offline logon = yes" in smb.conf)
  cached_login = yes
  # authenticate using kerberos
  krb5_auth = yes
  # when using kerberos, request a "FILE" krb5 credential cache type
  # (leave empty to just do krb5 authentication but not have a ticket
  # afterwards)
  krb5_ccache_type = FILE
  # make successful authentication dependend on membership of one SID
  # (can also take a name)
  ;require_membership_of =
  silent = yes

The file /etc/pam.d/gnome-screensaver then becomes:

auth    sufficient      pam_unix.so nullok_secure
auth    sufficient      pam_winbind.so use_first_pass
auth    required        pam_deny.so

And also the file /etc/pam.d/common-auth is changed:

auth    optional        pam_group.so
auth    sufficient      pam_unix.so nullok_secure  use_first_pass
auth    sufficient      pam_winbind.so use_first_pass
auth    required        pam_deny.so

 

 

Taken from the site - ]]>http://help.ubuntu.ru/wiki/%D0%B2%D0%B2%D0%BE%D0%B4_%D0%B2_%D0%B4%D0%BE%...]]>

 

To limit the domain user's login to the machine, you need to add

/etc/pam.d/login

account required pam_access.so

и в /etc/security/access.conf

- : group : ALL
 

 

0 0

Share the article with your friends in social networks, maybe it will be useful to them.


If the article helped you, you can >>thank the author<<