Kerberos authentification setup example for the Linux version of 1С:Enterprise server





The article is applicable to 1С:Enterprise versions starting from 8.1.12 and 8.2.8.

This example describes how to set up Kerberos authentication for a 1С:Enterprise 8.1 server in a simple system that consists of three computers: a domain controller, a central server of a 1C:Enterprise cluster, and a workstation.

The setup procedure for a 1C:Enterprise 8.2 server is similar, with the following differences:

  • Replace usr1cv81 with usr1cv82
  • Replace grp1cv81 with grp1cv82
  • Replace /opt/1C/v8.1 with /opt/1C/v8.2

Description of the system used in this example

The system includes the following computers:

  • Active Directory domain controller
    • Host name: main
    • IP address: 192.168.29.150
    • Domain name: krb.local
  • Central server of a 1C:Enterprise cluster
    • Operating system: Fedora 6
    • Host name: srv1c
    • IP address: 192.168.29.151
    • MIT Kerberos, which supports the RC4-HMAC algorithm (krb5-workstation package)
  • Workstation

Domain controller setup

In this example we assume that Active Directory domain controller is configured and running. To set up Kerberos authentication, perform the following steps:

  1. Manually register all of the Linux computers in the DNS server. Windows computers are registered automatically once they are added to the domain. In this example you have to register the central server of the 1С:Enterprise cluster manually (as it runs the Linux version of the server) and add the workstation to the domain (it will be registered automatically).
  2. Create the account for use in authorization requests to the 1С:Enterprise server. In this example it is the user usr1cv8 with the password pass1cv8. In the account properties, clear the check box Use DES encryption types with this account. If your Kerberos version does not support the RC4-HMAC coding algorithm, select this check box.
  3. For the user usr1cv8, generate a secret key file. Use the ktpass utility available in the Windows Support Tools package (you can find it in the SUPPORT subdirectory of the Windows installation disc).

Run the ktpass command-line utility with the following options :

C:\>ktpass -princ usr1cv81/srv1c.krb.local@KRB.LOCAL -mapuser usr1cv8 -pass pass1cv8-out
usr1cv81.keytab C:\>

If the RC4-HMAC algorithm is not supported, use the following options:

C:\>ktpass -crypto DES-CBC-CRC -princ usr1cv81/srv1c.krb.local@KRB.LOCAL 

 -mapuser usr1cv8 -pass pass1cv8-out usr1cv81.keytab 

C:\>

This creates the usr1cv81.keytab file in the current directory (in this example it is the root of drive C:). The service member name usr1cv81/srv1c.krb.local is linked to the user usr1cv8.



Pay attention to the difference between the names usr1cv81 and usr1cv8. In this example usr1cv81/srv1c.krb.local@KRB.LOCAL is a stardard service name. It includes the local user name used to run the 1C:Enterprise server on the central cluster server (usr1cv81). The name usr1cv8 in the mapuser option is the domain user name created in step 2

The pass option specifies the password for the usr1cv8 account: pass1cv8.

The out option specifies the key file name. In this example it is usr1cv81.keytab.

Central 1C:Enterprise cluster server setup

In this example we assume that a 1С:Enterprise server cluster is configured and running on the central cluster server.

First, specify the DNS server for the central cluster server. It must be the DNS domain controller. The setup depends on the Linux distribution package that you use, in this example you have to edit the /etc/resolv.conf file manually by adding the IP address of the domain controller, so that the file includes the following lines:

srv1c:~# cat /etc/resolv.conf

nameserver 192.168.29.150

search krb.local



srv1c:~#

Then check the work of the DNS. Run the ping command:

srv1c:~# ping main -c 1 

PING main.krb.local (192.168.29.150) 56(84) bytes of data.

64 bytes from 192.168.29.150: icmp_seq=1 ttl=128 time=0.177 ms

---main.krb.local ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt
min/avg/max/mdev = 0.177/0.177/0.177/0.000 ms srv1c:~#

Computers that take part in the authentication cannot have a big system clock difference, as authentication packages (tickets) have a time limit. Therefore, you need to synchronize the time of the central cluster server with the domain controller. Use the ntpdate command:

srv1c:~# ntpdate main 

4 Jun 11:51:53 ntpdate[2527]: step time server 192.168.29.150 offset -56.766439 sec

srv1c:~# 

Then set up Kerberos. Edit the /etc/krb5.conf file. You will need the NETBIOS name of the domain controller. As a rule, it is the domain name written in uppercase. In this example it is KRB.LOCAL.

The resulting /etc/krb 5.conf file looks as follows:

srv1c:~# cat /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 = KRB.LOCAL

dns_lookup_realm = false

dns_lookup_kdc = false

default_tkt_enctypes = rc4-hmac

default_tgs_enctypes = rc4-hmac



[realms]

KRB.LOCAL = {

    kdc = main.krb.local:88

    default_domain = krb.local

}



[domain_realm]

krb.local = KRB.LOCAL

.krb.local = KRB.LOCAL

KRB.LOCAL = KRB.LOCAL

.KRB.LOCAL = KRB.LOCAL



[kdc]

profile = /var/kerberos/krb5kdc/kdc.conf



[appdefaults]

pam = {

    debug = true

    ticket_lifetime = 36000

    renew_lifetime = 36000

    forwardable = false

    krb4_convert = false

}



srv1c:~#

If the RC4-HMAC algorithm is not supported, the default_tkt_enctypes and default_tgs_enctypes parameters must have the following values:

...

default_tkt_enctypes = des-cbc-crc des-cbc-md5

default_tgs_enctypes = des-cbc-crc des-cbc-md5

...

Then check the work of the authentication system. Run the kinit <name> command, where the name is the name of any user registered in the krb.local domain. In this example the name is "user". Then enter the password of that user and press Enter. If the application does not display any messages, everything is all right.

Use the klist command to check the result. As you can see in the listing below, a ticket-granting ticket is received from the KDC (Key Distribution Center). The domain controller, the so-called ticket-granting ticket, performs this function. Then use the kdestroy command to clear the local ticket cache and return to the initial state.

srv1c:~# kinit user

Password for user@KRB.LOCAL:

srv1c:~# klist

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: user@KRB.LOCAL

Valid starting  Expires  Service principal

06/04/08 11:29:21 06/04/08 21:28:28 krbtgt/KRB.LOCAL@KRB.LOCAL 

renew until 06/05/08 11:29:21

 

Kerberos 4 ticket cache: /tmp/tkt0

klist: You have no tickets cached

srv1c:~#kdestroy

srv1c:~#

Copy the usr1cv81.keytab secret key file that you created during the domain controller setup to the central server of the 1C:Enterprise cluster, to the 1C:Enterprise server installation directory (the default directory is /opt/1C/v8.1/i386). Then set the file owner and rights as follows:

srv1c:~# cd /opt/1C/v8.1/i386

srv1c:i386# chown usr1cv81:grp1cv81 usr1cv81.keytab

srv1c:i386# chmod 600 usr1cv81.keytab

srv1c:i386#

You can store this file to any other directory. If you do, change the value of the SRV1CV8_KEYTAB in the configuration file, it stores the secret key file location.

Then use the klist command to check that you did everything in the right way:

srv1c:~# klist -e -k -t /opt/1C/v8.1/i386/usr1cv81.keytab

The command execution result should look as follows:

Keytab name: FILE:/opt/1C/v8.1/i386/usr1cv81.keytab

KVNO Principal

---- ---------------------------------------------------------------------

 13 usr1cv81/srv1c.krb.local@KRB.LOCAL (ArcFour with HMAC/md5)

If the RC4-HMAC algorithm is not supported, the command execution result looks as follows:

Keytab name: 

FILE:/opt/1C/v8.1/i386/usr1cv81.keytab

KVNO Principal

---- --------------------------------------------------------------------- 

13 usr1cv81/srv1c.krb.local@KRB.LOCAL (DES cbc mode with RSA-MD5)

You can see that the secret key file contains exactly what you need. The Principal column contains the service name that you specified during the creation of the secret key file and the correct encryption algorithm (ArcFour with HMAC/md5 for RC4-HMAC or DES cbc mode with RSA-MD5 for DES).

Let us check whether Kerberos can work without a password using the secret key. Use the kinit command to specify that the authentication information is read from a file (in this example it is /opt/1C/v8.1/i386/usr1cv81.keytab) and the key for the usr1cv81/srv1c.krb.local@KRB.LOCAL service is read from that file. As a result, the kinit command should not display any messages or ask for passwords, and it should return the control back to the command line:

srv1c:~# kinit-k -t /opt/1C/v8.1/i386/usr1cv81.keytab usr1cv81/srv1c.krb.local@KRB.LOCAL

srv1c:~# 

Use the klist command to check the result. It should look like this:

srv1c:~# klist 

Ticket cache: FILE:/tmp/krb5cc_0 

Default principal:usr1cv81/srv1c.krb.local@KRB.LOCAL

Valid starting  Expires       Service principal

06/04/08 11:44:54 06/04/08 21:43:58 krbtgt/KRB.LOCAL@KRB.LOCAL

        renew until 06/05/08 11:44:54



Kerberos 4 ticket cache: /tmp/tkt0 

klist: You have no tickets cached 

srv1c:~#

If something is set up in a wrong way, the result might look like this:

srv1c:~# klist

klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000

Kerberos 4 ticket cache: /tmp/tkt1000

klist: You have no tickets cached 

srv1c:~#

If the check is successful, the 1C:Enterprise cluster server is now capable of processing authentication requests. You do not need to restart the server, except the scenario where you change the location of the secret key file in the configuration file.


Comments
0
Add comment