SQUID и Kerberos-авторизация через Active Directory [RTzRa’s hive]

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:

  1. 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:

    1. For a DHCP configuration, go to section Session Manager
      IP Configuration
      and check the configuration is
      correct.
    2. 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
  2. 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:

  1. Install the package first

  2. 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:

  3. Edit the configuration file:

  4. and copy the following data into the file:

    1. Replace osm.test.demo by the FQDN of the Session Manager in
      your environment.
    2. Replace TEST.DEMO by your Active Direcory domain in upper
      case characters
  5. Create a folder test in the web server root

  6. Create a /var/www/test/index.php file and paste the following
    content in it:

  7. 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:

  1. The server time on all servers is correctly synchronized and
    operational
  2. Browser is set-up correctly
  3. No firewall issues on the OSM node
  4. 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 is osm
  • hostname -f – the expected response is osm.test.demo

If either of the responses is not as expected, follow the steps below to
correct the configuration and then retest:

  1. 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 define osm as hostname.
  2. Edit the /etc/hosts file and ensure it contains the following
    lines, using the IP address and Session Manager FQDN applicable to
    your environment:

  3. If you made any modification to the hostname configuration file
    or the /etc/hosts file, please reboot your server.

  4. After reboot make sure the expected response is obtained for the
    hostname and hostname -f commands
Похожее:  Идентификация, аутентификация и авторизация пользователей

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *