Active directory and kerberos auth method¶
The Kerberos authentication protocol provides a mechanism for
authentication – and mutual authentication – between a client and a
server, or between one server and another server.
Active directory dns¶
Using the DNS server that is provided on the Active Directory server
simplifies the requirements for FQDN when using Kerberos. To check that
the DNS server is working correctly, perform the following steps:
Open the
/etc/resolv.conf
file on the Session Manager server and
ensure that the name server is the Domain Controller’s IP address.
If not then:- For a DHCP configuration, go to section Session Manager
IP Configuration and check the configuration is
correct. - For a static IP configuration, change the system primary DNS to
be the Active Directory Domain controller IP. For further
information refer to the Static IP Address
Configuration section.nameserver 192.168.0.200 search test.demo
- For a DHCP configuration, go to section Session Manager
Save the file and verify that the name resolution works.
Allowtgtsessionkey¶
There is a key called AllowTgtSessionkey in the Windows registry
that controls whether a client application is allowed to decrypt the
session key of a Kerberos Ticket Granting Ticket (TGT). This capability
must be enabled.
Apache and kerberos¶
Please follow the steps below:
Install the package first
Enable the Apache module. The Apache module should be loaded
automatically after installing the package. If the module does not
load, enter the command below:Edit the configuration file:
and copy the following data into the file:
- Replace
osm.test.demo
by the FQDN of the Session Manager in
your environment. - Replace
TEST.DEMO
by your Active Direcory domain in upper
case characters
- Replace
Create a folder
test
in the web server rootCreate a
/var/www/test/index.php
file and paste the following
content in it:Restart the Apache service
Apache group¶
The system default group used by Apache is :
- For Ubuntu: www-data
- For CentOS / RHEL 7: apache
If for some reason the system overrides the system default value or if
you want to check it, the following command line will give you the group
name used by apache on your system:
Client compatibility¶
The SSO feature is compatible with OVD clients running on a Windows
workstation that is joined to the Active Directory domain. SSO is
compatible with the OVD Enterprise Desktop Client and OVD Web Access
clients using a Windows workstation. It is not compatible with the
Enterprise Mobile Client (Android, iOS) or the Enterprise Desktop Client
on Linux and Mac platforms or the Web Access clients running on Linux or
Mac.
Clock skew¶
If there is an issue in authenticating OVD with Kerberos, turn on the
Apache error logs and check the reports for a Clock skew too great
error:
[error] [client 192.168.0.65] krb5_get_init_creds_password() failed: Clock skew too great
This error indicates that the time on the Session Manager is not
synchronized with the time on the Active Directory Domain Controller.
Run the ntpdate command to fix the issue and check for the possible
reasons why the ntp service is not synchronizing it.
Create a service ticket¶
Up to this point, the system has been configured so that the Session
Manager server is able to connect to the Active Directory domain. The
next step is to get the Kerberos service keys in a keytab file so that
the data can be used by the Apache web server on the Session Manager
server. Samba is used to set the service principle(s) for Apache.
Dns issues¶
If the result from net ads join test failed as described in section
Joining the Domain is as follows:
No DNS domain configured for osm. Unable to perform DNS Update.
DNS update failed!
Then the possible reasons are
- Invalid system hostname
- Invalid system network name in
/etc/hosts
- Invalid system network name in the
smb.conf
configuration for the
netbios name
To resolve this issue, configure the system hostname and system network
name for the Session Manager correctly and then remove the workstation
from Active Directory and re-register it again.
Enterprise desktop client¶
This section applies to the Enterprise Desktop Client (EDC) running on a
Windows workstation.
Fqdn and dns compatiblity¶
Windows Kerberos requires the use of Fully Qualified Domain
Name (FQDN), it will not work with IP addresses. Each server in a Kerberos
authentication realm must be assigned a FQDN that is forward-resolvable.
The Kerberos protocol also expects the server’s FQDN to be
reverse-resolvable. The reverse and forward lookup for a FQDN can be
tested using the nslookup command.
Joining the domain¶
The next step is to install and configure Samba so that the Session
Manager server can be added to the Active Directory domain using
Kerberos.
Network overview¶
In order to use Kerberos with the OVD Session Manager, the firewall must be
configured to allow authentication. Refer to Firewall and Ports
for instructions.
Server environment¶
The server environment must include a Microsoft Domain Controller as
well as a typical OVD server farm.
The Microsoft Domain Controller (DC) must have the following
characteristics:
- Active Directory is installed and functional
- DNS Server is installed and functional
- Configured as an NTP host server
- Microsoft functional level 2008R2, or 2022R2
The OVD server farm must be able to access the Domain Controller and
vice-versa. The OVD farm consists of the following:
Session manager ip configuration¶
The Session Manager IP address may be established either by using DHCP
or by using a static IP configuration. In the case that a DHCP
configuration is used and the DHCP service is not provided by the Active
Directory server, the following must be ensured:
- The DHCP server must always provide the same IP to the Session
Manager (MAC address match) - The DHCP server must provide the Session Manager with the IP address
of the active Directory server as the primary DNS server
It is highly recommended to perform the above steps before proceeding
further in the documentation.If it is not possible to validate the above
steps then a possible workaround is to configure the Session Manager
with a static IP address.
Static ip address configuration¶
Generally, the DNS information is stored in the /etc/resolv.conf
file. Sometimes, when you modify the file to have a specific DNS server
IP address, it may not be persistent because of the system configuration
and the modification may change when the system is rebooted or the
network service is restarted.
On Ubuntu and RHEL/CentOS systems, the DNS configuration can also be
defined in the global network configuration. In turn, this will
overwrite the DNS modification made in /etc/resolv.conf. For these
reasons, it is recommended to modify the DNS information directly in the
global network configuration file.
Time synchronization¶
Time Synchronization is critical for Kerberos authentication to work.
Please follow the Time Synchronization documentation.
Understanding kerberos concepts¶
The Kerberos authentication protocol is standard on all versions of
Windows. A typical Kerberos implementation consists of 3 server
entities:
- Key Distribution Center (KDC) which typically is installed on the
Domain Controller (the primary Microsoft Active Directory server); - A client workstation that is a part of the domain; and
- A server with the desired service to access.
An overview of a typical Kerberos workflow can be found at the Microsoft kerberos guide
Validate test case¶
If the test from section Validate the Configuration
does not work, check the
items below first:
- The server time on all servers is correctly synchronized and
operational - Browser is set-up correctly
- No firewall issues on the OSM node
- Check that the
auth_kerb
module is enabled in Apache and ensure
that the module is present and loaded.
Verification¶
To verify that the installation and configuration were successful,
perform the following test using kinit:
Check that the Ticket Granting Ticket (TGT) is correctly configured by
using the following commands:
Information similar to that shown below should be displayed:
In order to destroy the active TGT, enter the following command:
Ошибка “kerberos_ldap_group: error: error while binding to ldap server with sasl/gssapi: local error”
Необходимо установить библиотеку Cyrus-SASL, в убунте она называется libsasl2-modules-gssapi-mit
Создаем keytab-файл на контроллере домена
keytab-файл это «связка ключей», файл содержащий в себе одну или несколько записей – ключей, которые используются вместо логина/пароля при запросе доступа у сервера KDC к какому-либо ресурсу. Другими словами, машина предоставляет данный файл серверу KDC как подтверждение своей достоверности, когда запрашивает у контроллера домена (KDC) доступ к какому-либо ресурсу (например доступ к службе или сетевому каталогу). В большинстве случаев, при настройке какой-либо службы в связке с Kerberos проблемы возникают именно на данном этапе, т.к. именно этот файл является связующим звеном между Windows 2008 и Linux (в нашем случае – Debian). Проблемы обычно связаны с различными типами шифрования, которые поддерживает Windows, но не поддерживает Linux и наоборот.
На контроллере домена даем команду (запустить из-под администратора):
C:Windowssystem32ktpass.exe /princ HTTP/[email protected] /mapuser [email protected] /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass rndpass /out C:tmpproxy.keytab
Где proxy.mydomain.ru – FQDN нового прокси-сервера, а [email protected] – логин пользователя, от имени которого будут делаться запросы в AD
Теперь этот ключ Kerberos необходимо БЕЗОПАСНО скопировать на наш прокси (например чрез WinSCP) и приступить к следующему шагу.
Остался последний этап – отображать красивую статистику посещений сайтов пользователями. Самый простой и красивый инструмент для этого – LightSquid.
Необходимо поставить пакет libnet-ldap-perl:
# apt-get install libnet-ldap-perl
Очень хочется чтобы в отчете фигурировало полное ФИО пользователя, а не доменное имя или IP-адрес. Для этого нужно заменить оригинальный файл /usr/share/lightsquid/ip2name/ip2name.squidauth следующим:
#contributor: esl#specialy for squid with turned on user authentication#simple version use strict;use warnings;use Net::LDAP;use Encode; my$ldap;my$message;my%hDisplayName; sub StartIp2Name(){my$server="ldap://dc.mydomain.ru";$ldap= Net::LDAP->new($server);returnif(!defined$ldap);$message=$ldap->bind(q(mydomain.rulightsquid), password =>"my_password");} sub Ip2Name($$$){# $Lhost,$user,$Ltimestampmy$Lhost=shift;my$user=shift;$user=URLDecode($user);#decode user name$user=substr($user,0,index($user,"@mydomain.ru"));return$Lhostif($usereq"-");return$userif(!defined$ldap);return$userif($message->code()); if(!defined$hDisplayName{$user}){ my$result=$ldap->search( base =>"dc=mydomain,dc=ru", filter =>"(&(objectCategory=person)(objectClass=user)(sAMAccountName=".$user."))",); my$first_entry=$result->entry(0);if(!defined$first_entry){return$Lhost;} my$pure_displayName=$first_entry->get_value("displayName");$pure_displayName=~s/ /_/g; Encode::from_to($pure_displayName,'utf-8','windows-1251'); $hDisplayName{$user}=$pure_displayName;} return$hDisplayName{$user};} sub StopIp2Name(){returnif(!defined$ldap);$message=$ldap->unbind;} #warning !!!1;
В этом файле исправляем нижеуказанные строки на свои:
...my$server="ldap://dc.mydomain.ru";...$message=$ldap->bind(q(MYDOMAIN.RULightSquid), password =>"PASSWORD");... base =>"dc=MYDOMAIN,dc=RU",...
Теперь в /etc/lightsquid/lightsquid.cfg включаем преобразование логина в ФИО:
$ip2name="squidauth"
Запускаем /usr/share/lightsquid/check-setup.pl и если все хорошо, можно запускать /usr/share/lightsquid/lightparser.pl
В папке /var/lib/lightsquid/report должны появиться отчеты, которые можно поглядеть по адресу: http://192.168.1.1/lightsquid/
System hostname definition¶
Before proceeding, make sure that the Session Manager server is
configured correctly by entering the following commands and checking
that the response is as expected:
hostname
– the expected response isosm
hostname -f
– the expected response isosm.test.demo
If either of the responses is not as expected, follow the steps below to
correct the configuration and then retest:
- Make sure the system hostname is defined correctly (osm) and does
not contain the network/domain name (test.demo) by editing the file
/etc/hostname
to defineosm
as hostname. Edit the
/etc/hosts
file and ensure it contains the following
lines, using the IP address and Session Manager FQDN applicable to
your environment:If you made any modification to the hostname configuration file
or the/etc/hosts
file, please reboot your server.- After reboot make sure the expected response is obtained for the
hostname
andhostname -f
commands