Setting up an authentication server using the Kerberos + LDAP bundle based on ROSA Enterprise Linux Server
Introduction
Continuation of a series of tutorials. Previous parts:
Deploying DNS / DDNS and DHCP server on ROSA Enterpise Linux Server in a few minutes
Mail server based on ROSA Server Enterpise Linux in a few minutes
Simple domain based on ROSA Enterprise Linux Server and Samba 3 with roaming profile support
In this article, we will look at creating a server for centralized user authentication via Kerberos, as well as Kerberos authentication with storing profile information in the LDAP directory tree. As a nice little thing - automatically create profiles in the home directory when you connect.
To configure the authentication server, we need ROSA Enterprise Linux Server (hereinafter referred to as RELS) and any Linux-based workstation. This article will use ROSA Desktop Fresh 2012 as a workstation with the KDE desktop.
A bit about the Kerberos protocol itself from Wikipedia:
')
“Kerberos is a network authentication protocol that allows data to be transmitted over unsecured networks for secure authentication. Focused primarily on the client-server model and provides mutual authentication - both users through the server confirm the identity of each other. "
From myself I would add that this protocol is an obligatory industrial standard for the organization of authentication in enterprises, and most importantly, it is necessary for creating systems using single sign-on technology, better known as Single Sign-On. At the moment, the current version of the protocol is Kerberos 5. This protocol is used in Active Directory (starting with Windows 2000), 389 Directory Server and many other places where you need to create at least some serious solution for centralized user authentication on the network. Including it is used in ROSA Directory Server (hereinafter referred to as RDS).
About terminology used when working with Kerberos:
Principal - a special unique entity, which can issue a ticket. Consists of three parts: the base, instance and region.
The basis is the first part of the Kerberos principal. If it is a user, then it corresponds to its name. If service is the name of the service. The instance - the second part, serves to clarify the first part. May not be contained in the name of the principal, if there is, then this is his description. In the case of a host, its fqdn. The area is the last part.
Ticket - data used by the client to authenticate with the server from which the client requests the service. Confirm the identity of the user or service.
KDC - Kerberos Key Issuing Center
REALM (realm) - Kerberos realm. As a rule, it corresponds to a domain name written in upper case.
As an introduction, more than enough. Details about the protocol, its implementations can be read on the Web, since this is material for more in-depth study and one article here is not enough.
Preparation and Deployment
We will assume that your OS is already installed, as well as the RDS component.
To configure the authentication server, we need a pre-installed and configured DNS server, the configuration of which we considered in one of the previous articles, as well as a working NTP.
As in all previous articles of the cycle, the following network parameters are used:
Domain Name: rosa.int
IP Address: 192.168.100.1
We will also assume that DNS, LDAP and Kerberos are running on the same physical server.
Other details of the setting, read in previous articles of the cycle.
Since the installation we have already studied in detail, we focus on the features of the setting. Actually, we will begin with the nuances of configuring DNS.
First we need to log in to the ROSA Management Console at the hostname / mmc address and go to the “DNS zones” section. For the existing zone (in our case, rosa.int), we need to create an alias to the host we need, which will continue to be the KDC (Key Distribution Center). Key distribution center, I mean. In this section, click on the link with the FQDN-name, or on the icon representing two computers.
There you need to find the record responsible for the named-server. In my case, this is ns.rosa.int. We are looking for the “Change” icon, in the window that opens, click the “Add” button and in the text field that appears, we write any word we like in lower case, which will be the name of KDC. For example, kerberos.
Checking:
Now you can go to install the necessary components for the future authentication server, for which we follow in ROSA Server Setup and select the Kerberos with RDS backend component. We wait until the installation of all necessary components is completed and click "Continue" for the initial setup. This wonderful form will open here:
I will give some explanations for the screenshot above:
Just in case I will give advice. At the time of this writing, there was an extremely unpleasant bug in ROSA Server Setup, which led to the fact that if you filled out one of the required fields on the first attempt, then a branch for Kerberos was created with data in the LDAP database anyway. This led to the fact that with the re-filled form, but with the correct values, it was impossible to continue further tuning. In the next versions, this problem is guaranteed to be fixed, so just in case, run the command yum update in the terminal emulator before installing.
If you still have this error, take any editor for LDAP. It'll even come down as simple as luma . As a rule, it is in the repositories of any distribution. Connect to the server and delete the following entries completely:
Just in case, check the existence of the following entries:
If there are, delete too. After that, restart the installation wizard.
To connect to the LDAP server in order to edit the contents of the branches, use the following parameters:
uid = LDAP Admin, ou = System Accounts, dc = rosa, dc = int
In the settings of luma use Simple authentication. The password is the one you specified when setting up using ROSA Server Setup. Naturally, instead of dc = rosa, dc = int your domain should be specified. Connection encryption is not applied.
Now we need to (N!) Configure NTP both on the server and clients, otherwise our client machines may not connect due to incorrect clock settings.
On the server, it is enough to do:
sudo yum install ntp
sudo chkconfig ntpd on
sudo vim /etc/ntp.conf
As we can see, NTP servers are already registered. It remains only to command:
ntpdate pool.ntp.org
service ntpd start.
Check and synchronize clocks on client systems. This is a very important setting point.
Creation of principals
Before starting the operation check, you need to create a user on which we check the operation of the Kerberos server in action.
To get started, let's look at the list of Kerberos principals and make sure that all service principals are in place:
Now we will create our user and principal Kerberos. To do this, we go to the ROSA Management Console and add a test user through the "Add user" in the main menu. Fill in the login and password fields. If you scroll the form a little lower, you can see the parameters related to the settings of Kerberos. You can set the following parameters:
I think it makes no sense to explain the meaning of all three points. It's pretty obvious.
In case of successful and correct filling of the fields, after clicking on the "Confirm" button, the corresponding notification will appear:
Check in action
To begin with, let's check that everything really works by means of console utilities. This will allow you to immediately track errors that occur. First you need to install the krb5-workstation package, then run the kinit command on the command line, and after entering the password, enter the klist command to verify the correctness of the request.
It will look something like this:
If you see everything exactly as in the listing above, then the right Kerberos ticket arrives, which means that you can proceed to setting up the workplace.
As a client operating system, I used the Linux ROSA Desktop Fresh 2012 distribution. There is already a wizard for setting up connections to such servers. For the rest of the distributions, I will provide the listings of the working configuration files a little later, so that you can use any other distribution kit that you personally like.
To connect to the RELS server, you need to open the "Desktop Settings" and select to find the icon that says "Authentication". Select the item Kerberos 5. Then, we register the server, as indicated in the screenshot. Pay attention to the placed checkboxes. If you leave the last one activated, the packages and their dependencies necessary for the connection may not be installed.
In the next screenshot, please pay attention to two options: “Use local file with user data” and “Use LDAP with user data.”
If you use the “local file with user data” item, then you will have to make sure that an account with the correct name exists on the local machine. In case of its absence on one of the parties, create a user with the same login on the server and client. But ask him different passwords. This is not very good and adds a lot of headache to the administrator. In addition, due to the rather large default timeouts, the first login using this login method will be very slow. The choice of the second item is more correct: “Use LDAP with user data”. In this case, you do not need to create two accounts, all data will be taken from the server. What, you see, much nicer. Be careful, the address must be specified as an IP address, not a FQDN name. Then click on the button "Get DN data".
Checking the correctness of obtaining a ticket is very simple and similar to the way we checked it on the server. That is, the command klist, but without any additional parameters. Since the machine is already included in the Kerberos area and the ticket must arrive at the entrance to the system.
And the promised configuration file listings:
/etc/krb5.conf
/etc/ldap.conf
/etc/nsswitch.conf
/etc/pam.d/system-auth
If someone needs to authenticate exclusively through LDAP without using Kerberos, then everything is much simpler.
Likewise, run the setup wizard, only instead of the Kerberos item you need to select LDAP. For the ROSA Marathon 2012 (LTS) and ROSA Desktop Fresh 2012 distributions, all the necessary packages required for the connection are already included in the distribution. The rest should be aware that to configure the client will need the following packages: openldap-clients, pam_ldap, autofs.
At this stage, you must specify the address of the LDAP server. Like last time, we do not forget to specify the address in the form of octets. Otherwise, a non-working configuration file will be generated (however, it can always be corrected by hand in case anything happens). The user base is determined automatically by clicking on the button "Get DN". As in the previous example, it is necessary to uncheck the flag “Offline mode”, otherwise the setting will be made not quite right.
You can also check the operation in the console using the getent paswd command, or you can run the command su username_v_BD_ldap. The first command will display a list of users, among which will be listed users of the LDAP directory. During the execution of the second command, the user will be logged in using the user credentials of the LDAP directory and automatically create a directory of the authenticated user within the / home directory.
Examples of configuration files:
Contents of ldap.conf:
And finally, system-auth:
Conclusion
That's all, perhaps. We learned how to quickly and easily create our own authentication server using Kerberos and LDAP. In the future, the kerberization can be used for various purposes. For example, associate Kerberos with a PostgreSQL server and use Kerberos principals for login. Or the creation of infrastructure Single Sign-On and much more.
Traditionally, I hope that the material is useful as a beginner, as well as just lazy (in a good way) system administrators.
Practical comments, substantive questions and feature quotes are always welcome.
Continuation of a series of tutorials. Previous parts:
Deploying DNS / DDNS and DHCP server on ROSA Enterpise Linux Server in a few minutes
Mail server based on ROSA Server Enterpise Linux in a few minutes
Simple domain based on ROSA Enterprise Linux Server and Samba 3 with roaming profile support
In this article, we will look at creating a server for centralized user authentication via Kerberos, as well as Kerberos authentication with storing profile information in the LDAP directory tree. As a nice little thing - automatically create profiles in the home directory when you connect.
To configure the authentication server, we need ROSA Enterprise Linux Server (hereinafter referred to as RELS) and any Linux-based workstation. This article will use ROSA Desktop Fresh 2012 as a workstation with the KDE desktop.
A bit about the Kerberos protocol itself from Wikipedia:
')
“Kerberos is a network authentication protocol that allows data to be transmitted over unsecured networks for secure authentication. Focused primarily on the client-server model and provides mutual authentication - both users through the server confirm the identity of each other. "
From myself I would add that this protocol is an obligatory industrial standard for the organization of authentication in enterprises, and most importantly, it is necessary for creating systems using single sign-on technology, better known as Single Sign-On. At the moment, the current version of the protocol is Kerberos 5. This protocol is used in Active Directory (starting with Windows 2000), 389 Directory Server and many other places where you need to create at least some serious solution for centralized user authentication on the network. Including it is used in ROSA Directory Server (hereinafter referred to as RDS).
About terminology used when working with Kerberos:
Principal - a special unique entity, which can issue a ticket. Consists of three parts: the base, instance and region.
The basis is the first part of the Kerberos principal. If it is a user, then it corresponds to its name. If service is the name of the service. The instance - the second part, serves to clarify the first part. May not be contained in the name of the principal, if there is, then this is his description. In the case of a host, its fqdn. The area is the last part.
Ticket - data used by the client to authenticate with the server from which the client requests the service. Confirm the identity of the user or service.
KDC - Kerberos Key Issuing Center
REALM (realm) - Kerberos realm. As a rule, it corresponds to a domain name written in upper case.
As an introduction, more than enough. Details about the protocol, its implementations can be read on the Web, since this is material for more in-depth study and one article here is not enough.
Preparation and Deployment
We will assume that your OS is already installed, as well as the RDS component.
To configure the authentication server, we need a pre-installed and configured DNS server, the configuration of which we considered in one of the previous articles, as well as a working NTP.
As in all previous articles of the cycle, the following network parameters are used:
Domain Name: rosa.int
IP Address: 192.168.100.1
We will also assume that DNS, LDAP and Kerberos are running on the same physical server.
Other details of the setting, read in previous articles of the cycle.
Since the installation we have already studied in detail, we focus on the features of the setting. Actually, we will begin with the nuances of configuring DNS.
First we need to log in to the ROSA Management Console at the hostname / mmc address and go to the “DNS zones” section. For the existing zone (in our case, rosa.int), we need to create an alias to the host we need, which will continue to be the KDC (Key Distribution Center). Key distribution center, I mean. In this section, click on the link with the FQDN-name, or on the icon representing two computers.
There you need to find the record responsible for the named-server. In my case, this is ns.rosa.int. We are looking for the “Change” icon, in the window that opens, click the “Add” button and in the text field that appears, we write any word we like in lower case, which will be the name of KDC. For example, kerberos.
Checking:
[rels @ rosa tmp] $ ping kerberos.rosa.int
PING ns.rosa.int (192.168.100.1) 56 (84) bytes of data.
64 bytes from rosa (192.168.100.1): icmp_seq = 1 ttl = 64 time = 0.011 ms
64 bytes from rosa (192.168.100.1): icmp_seq = 2 ttl = 64 time = 0.026 ms
64 bytes from rosa (192.168.100.1): icmp_seq = 3 ttl = 64 time = 0.022 ms
Now you can go to install the necessary components for the future authentication server, for which we follow in ROSA Server Setup and select the Kerberos with RDS backend component. We wait until the installation of all necessary components is completed and click "Continue" for the initial setup. This wonderful form will open here:
I will give some explanations for the screenshot above:
- Region - in fact, defines the area to which Kerberos is distributed. In most cases, this is the name of the domain being used in upper case.
- The KDC hostname is the server on which the key distribution server will be located. In our case, everything is hosted on the same machine. The FQDN of the server must be specified without a domain name. Those. instead of kerberos.rosa.int, just kerberos.
- DNS Domain - Domain Name. Actually in our case, coincides with the area.
- KDC port - the port for the key distribution server.
- Admin Server Port — The port through which Kerberos communicates with its database.
- The main key of the KDC database is the password for the Kerberos database.
- DNS lookup for the KDC — checks the DNS SRV records for Kerberos server information.
- DNS lookup for a domain — look for available Kerberos servers information in the TXT DNS field.
- Time shift - indicates the allowable time of the clock shift relative to the “reference”. As a reference, we will act as the Kerberos server, on which the NTP service is running. The offset time is indicated in seconds.
- Types of encryption TGS - supported encryption algorithms valid on the server issuing tickets. As a rule, does not touch.
- Types of encryption TKT - supported encryption algorithms for tickets issued by the server. As a rule, does not touch.
- Allowed encryption types are shuffling types for the session key.
- Allow low encryption type encryption types - in fact, allows you to allow the use of weak encryption algorithms. If you suffer from paranoia and need more security when connecting to the server, remove this checkbox.
Just in case I will give advice. At the time of this writing, there was an extremely unpleasant bug in ROSA Server Setup, which led to the fact that if you filled out one of the required fields on the first attempt, then a branch for Kerberos was created with data in the LDAP database anyway. This led to the fact that with the re-filled form, but with the correct values, it was impossible to continue further tuning. In the next versions, this problem is guaranteed to be fixed, so just in case, run the command yum update in the terminal emulator before installing.
If you still have this error, take any editor for LDAP. It'll even come down as simple as luma . As a rule, it is in the repositories of any distribution. Connect to the server and delete the following entries completely:
dn: ou = kerberos, @ SUFFIX @
dn: uid = kadmin, ou = System Accounts, @ SUFFIX @
dn: uid = kdc, ou = System Accounts, @ SUFFIX @
dn: cn = Kerberos Admins, ou = System Groups, @ SUFFIX @
dn: cn = Kerberos Readers, ou = System Groups, @ SUFFIX @
Just in case, check the existence of the following entries:
dn: relativeDomainName = kerberos, ou = @ DNSDOMAIN @, ou = @ DNSDOMAIN @, ou = DNS, @ SUFFIX @
dn: relativeDomainName = _kerberos._udp, ou = @ DNSDOMAIN @, ou = @ DNSDOMAIN @, ou = DNS, @ SUFFIX @
dn: relativeDomainName = _kerberos-master._udp, ou = @ DNSDOMAIN @, ou = @ DNSDOMAIN @, ou = DNS, @ SUFFIX @
dn: relativeDomainName = _kerberos-adm._tcp, ou = @ DNSDOMAIN @, ou = @ DNSDOMAIN @, ou = DNS, @ SUFFIX @
dn: relativeDomainName = _kpasswd._udp, ou = @ DNSDOMAIN @, ou = @ DNSDOMAIN @, ou = DNS, @ SUFFIX @
If there are, delete too. After that, restart the installation wizard.
To connect to the LDAP server in order to edit the contents of the branches, use the following parameters:
uid = LDAP Admin, ou = System Accounts, dc = rosa, dc = int
In the settings of luma use Simple authentication. The password is the one you specified when setting up using ROSA Server Setup. Naturally, instead of dc = rosa, dc = int your domain should be specified. Connection encryption is not applied.
Now we need to (N!) Configure NTP both on the server and clients, otherwise our client machines may not connect due to incorrect clock settings.
On the server, it is enough to do:
sudo yum install ntp
sudo chkconfig ntpd on
sudo vim /etc/ntp.conf
As we can see, NTP servers are already registered. It remains only to command:
ntpdate pool.ntp.org
service ntpd start.
Check and synchronize clocks on client systems. This is a very important setting point.
Creation of principals
Before starting the operation check, you need to create a user on which we check the operation of the Kerberos server in action.
To get started, let's look at the list of Kerberos principals and make sure that all service principals are in place:
Now we will create our user and principal Kerberos. To do this, we go to the ROSA Management Console and add a test user through the "Add user" in the main menu. Fill in the login and password fields. If you scroll the form a little lower, you can see the parameters related to the settings of Kerberos. You can set the following parameters:
- Using password policy
- Set the validity period of the principal
- Set the password expiration date of the principal
I think it makes no sense to explain the meaning of all three points. It's pretty obvious.
In case of successful and correct filling of the fields, after clicking on the "Confirm" button, the corresponding notification will appear:
Check in action
To begin with, let's check that everything really works by means of console utilities. This will allow you to immediately track errors that occur. First you need to install the krb5-workstation package, then run the kinit command on the command line, and after entering the password, enter the klist command to verify the correctness of the request.
It will look something like this:
kinit test@ROSA.INT
Password for test@ROSA.INT:
klist
Ticket cache: FILE: / tmp / krb5cc_500
Default principal: test@ROSA.INT
Valid starting Expires Service principal
10/19/11 01:46:33 10/20/11 01:46:33 krbtgt/ROSA.INT@ROSA.INT
renew until 10/26/11 01:46:33
If you see everything exactly as in the listing above, then the right Kerberos ticket arrives, which means that you can proceed to setting up the workplace.
As a client operating system, I used the Linux ROSA Desktop Fresh 2012 distribution. There is already a wizard for setting up connections to such servers. For the rest of the distributions, I will provide the listings of the working configuration files a little later, so that you can use any other distribution kit that you personally like.
To connect to the RELS server, you need to open the "Desktop Settings" and select to find the icon that says "Authentication". Select the item Kerberos 5. Then, we register the server, as indicated in the screenshot. Pay attention to the placed checkboxes. If you leave the last one activated, the packages and their dependencies necessary for the connection may not be installed.
In the next screenshot, please pay attention to two options: “Use local file with user data” and “Use LDAP with user data.”
If you use the “local file with user data” item, then you will have to make sure that an account with the correct name exists on the local machine. In case of its absence on one of the parties, create a user with the same login on the server and client. But ask him different passwords. This is not very good and adds a lot of headache to the administrator. In addition, due to the rather large default timeouts, the first login using this login method will be very slow. The choice of the second item is more correct: “Use LDAP with user data”. In this case, you do not need to create two accounts, all data will be taken from the server. What, you see, much nicer. Be careful, the address must be specified as an IP address, not a FQDN name. Then click on the button "Get DN data".
Checking the correctness of obtaining a ticket is very simple and similar to the way we checked it on the server. That is, the command klist, but without any additional parameters. Since the machine is already included in the Kerberos area and the ticket must arrive at the entrance to the system.
And the promised configuration file listings:
/etc/krb5.conf
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = ROSA.INT dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true /etc/ldap.conf
base dc=rosa,dc=int host 192.168.100.1 nss_base_group dc=rosa,dc=int?sub nss_base_shadow dc=rosa,dc=int?sub nss_base_passwd dc=rosa,dc=int?sub /etc/nsswitch.conf
passwd: files ldap shadow: files ldap group: files ldap hosts: mdns4_minimal files nis dns wins mdns4 networks: files services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files ldap aliases: files /etc/pam.d/system-auth
#%PAM-1.0 auth required pam_env.so auth sufficient pam_tcb.so shadow nullok prefix=$2a$ count=8 auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account sufficient pam_tcb.so shadow account sufficient pam_krb5.so use_first_pass account required pam_deny.so password required pam_cracklib.so try_first_pass retry=3 password sufficient pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8 password sufficient pam_krb5.so password required pam_deny.so session optional pam_mkhomedir.so skel=/etc/skel/ umask=0022 session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_tcb.so session optional pam_krb5.so If someone needs to authenticate exclusively through LDAP without using Kerberos, then everything is much simpler.
Likewise, run the setup wizard, only instead of the Kerberos item you need to select LDAP. For the ROSA Marathon 2012 (LTS) and ROSA Desktop Fresh 2012 distributions, all the necessary packages required for the connection are already included in the distribution. The rest should be aware that to configure the client will need the following packages: openldap-clients, pam_ldap, autofs.
At this stage, you must specify the address of the LDAP server. Like last time, we do not forget to specify the address in the form of octets. Otherwise, a non-working configuration file will be generated (however, it can always be corrected by hand in case anything happens). The user base is determined automatically by clicking on the button "Get DN". As in the previous example, it is necessary to uncheck the flag “Offline mode”, otherwise the setting will be made not quite right.
You can also check the operation in the console using the getent paswd command, or you can run the command su username_v_BD_ldap. The first command will display a list of users, among which will be listed users of the LDAP directory. During the execution of the second command, the user will be logged in using the user credentials of the LDAP directory and automatically create a directory of the authenticated user within the / home directory.
Examples of configuration files:
Contents of ldap.conf:
base dc=rosa,dc=int host 192.168.100.1 nss_base_group dc=rosa,dc=int?sub nss_base_shadow dc=rosa,dc=int?sub nss_base_passwd dc=rosa,dc=int?sub nsswitch.conf: passwd: files ldap shadow: files ldap group: files ldap hosts: mdns4_minimal files nis dns wins mdns4 networks: files services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files ldap aliases: files And finally, system-auth:
#%PAM-1.0 auth required pam_env.so auth sufficient pam_tcb.so shadow nullok prefix=$2a$ count=8 auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account sufficient pam_tcb.so shadow account sufficient pam_ldap.so use_first_pass account required pam_deny.so password required pam_cracklib.so try_first_pass retry=3 password sufficient pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8 password sufficient pam_ldap.so password required pam_deny.so session optional pam_mkhomedir.so skel=/etc/skel/ umask=0022 session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_tcb.so Conclusion
That's all, perhaps. We learned how to quickly and easily create our own authentication server using Kerberos and LDAP. In the future, the kerberization can be used for various purposes. For example, associate Kerberos with a PostgreSQL server and use Kerberos principals for login. Or the creation of infrastructure Single Sign-On and much more.
Traditionally, I hope that the material is useful as a beginner, as well as just lazy (in a good way) system administrators.
Practical comments, substantive questions and feature quotes are always welcome.
Source: https://habr.com/ru/post/169877/
All Articles