Linux active directory ssh

SSSD and Active Directory

This section describes the use of sssd to authenticate user logins against an Active Directory via using sssd’s “ad” provider. At the end, Active Directory users will be able to login on the host using their AD credentials. Group membership will also be maintained.

Prerequisites, Assumptions, and Requirements

• This guide does not explain Active Directory, how it works, how to set one up, or how to maintain it.
• This guide assumes that a working Active Directory domain is already configured and you have access to the credentials to join a machine to that domain.
• The domain controller is acting as an authoritative DNS server for the domain.
• The domain controller is the primary DNS resolver (check with systemd-resolve —status )
• System time is correct and in sync, maintained via a service like chrony or ntp
• The domain used in this example is ad1.example.com .

Software Installation

Install the following packages:

sudo apt install sssd-ad sssd-tools realmd adcli 

Join the domain

We will use the realm command, from the realmd package, to join the domain and create the sssd configuration.

Let’s verify the domain is discoverable via DNS:

$ sudo realm -v discover ad1.example.com * Resolving: _ldap._tcp.ad1.example.com * Performing LDAP DSE lookup on: 10.51.0.5 * Successfully discovered: ad1.example.com ad1.example.com type: kerberos realm-name: AD1.EXAMPLE.COM domain-name: ad1.example.com configured: no server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin 

This performs several checks and determines the best software stack to use with sssd. sssd can install the missing packages via packagekit, but we installed them already previously.

$ sudo realm join ad1.example.com Password for Administrator: 

That was quite uneventful. If you want to see what it was doing, pass the -v option:

$ sudo realm join -v ad1.example.com * Resolving: _ldap._tcp.ad1.example.com * Performing LDAP DSE lookup on: 10.51.0.5 * Successfully discovered: ad1.example.com Password for Administrator: * Unconditionally checking packages * Resolving required packages * LANG=C /usr/sbin/adcli join --verbose --domain ad1.example.com --domain-realm AD1.EXAMPLE.COM --domain-controller 10.51.0.5 --login-type user --login-user Administrator --stdin-password * Using domain name: ad1.example.com * Calculated computer account name from fqdn: AD-CLIENT * Using domain realm: ad1.example.com * Sending NetLogon ping to domain controller: 10.51.0.5 * Received NetLogon info from: SERVER1.ad1.example.com * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-hUfTUg/krb5.d/adcli-krb5-conf-hv2kzi * Authenticated as user: Administrator@AD1.EXAMPLE.COM * Looked up short domain name: AD1 * Looked up domain SID: S-1-5-21-2660147319-831819607-3409034899 * Using fully qualified name: ad-client.ad1.example.com * Using domain name: ad1.example.com * Using computer account name: AD-CLIENT * Using domain realm: ad1.example.com * Calculated computer account name from fqdn: AD-CLIENT * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Found computer account for AD-CLIENT$ at: CN=AD-CLIENT,CN=Computers,DC=ad1,DC=example,DC=com * Sending NetLogon ping to domain controller: 10.51.0.5 * Received NetLogon info from: SERVER1.ad1.example.com * Set computer password * Retrieved kvno '3' for computer account in directory: CN=AD-CLIENT,CN=Computers,DC=ad1,DC=example,DC=com * Checking RestrictedKrbHost/ad-client.ad1.example.com * Added RestrictedKrbHost/ad-client.ad1.example.com * Checking RestrictedKrbHost/AD-CLIENT * Added RestrictedKrbHost/AD-CLIENT * Checking host/ad-client.ad1.example.com * Added host/ad-client.ad1.example.com * Checking host/AD-CLIENT * Added host/AD-CLIENT * Discovered which keytab salt to use * Added the entries to the keytab: AD-CLIENT$@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab * Added the entries to the keytab: host/AD-CLIENT@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab * Added the entries to the keytab: host/ad-client.ad1.example.com@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab * Added the entries to the keytab: RestrictedKrbHost/AD-CLIENT@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab * Added the entries to the keytab: RestrictedKrbHost/ad-client.ad1.example.com@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab * /usr/sbin/update-rc.d sssd enable * /usr/sbin/service sssd restart * Successfully enrolled machine in realm 

By default, realm will use the Administrator account of the domain to request the join. If you need to use another account, pass it to the tool with the -U option.

Another popular way of joining a domain is using an OTP, or One Time Password, token. For that, use the —one-time-password option.

SSSD Configuration

The realm tool already took care of creating an sssd configuration, adding the pam and nss modules, and starting the necessary services.

Let’s take a look at /etc/sssd/sssd.conf :

[sssd] domains = ad1.example.com config_file_version = 2 services = nss, pam [domain/ad1.example.com] default_shell = /bin/bash krb5_store_password_if_offline = True cache_credentials = True krb5_realm = AD1.EXAMPLE.COM realmd_tags = manages-system joined-with-adcli id_provider = ad fallback_homedir = /home/%u@%d ad_domain = ad1.example.com use_fully_qualified_names = True ldap_id_mapping = True access_provider = ad 

Note

Something very important to remember is that this file must have permissions 0600 and ownership root:root, or else sssd won’t start!

Let’s highlight a few things from this config:

• cache_credentials: this allows logins when the AD server is unreachable
• home directory: it’s by default /home/@ . For example, the AD user john will have a home directory of /home/john@ad1.example.com
• use_fully_qualified_names: users will be of the form user@domain, not just user. This should only be changed if you are certain no other domains will ever join the AD forest, via one of the several possible trust relationships

Automatic home directory creation

What the realm tool didn’t do for us is setup pam_mkhomedir , so that network users can get a home directory when they login. This remaining step can be done by running the following command:

sudo pam-auth-update --enable mkhomedir 

Checks

You should now be able to fetch information about AD users. In this example, John Smith is an AD user:

$ getent passwd john@ad1.example.com john@ad1.example.com:*:1725801106:1725800513:John Smith:/home/john@ad1.example.com:/bin/bash 

$ groups john@ad1.example.com john@ad1.example.com : domain users@ad1.example.com engineering@ad1.example.com 

Note

If you just changed the group membership of a user, it may be a while before sssd notices due to caching.

Finally, how about we try a login:

$ sudo login ad-client login: john@ad1.example.com Password: Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-24-generic x86_64) . Creating directory '/home/john@ad1.example.com'. john@ad1.example.com@ad-client:~$ 

Notice how the home directory was automatically created.

You can also use ssh, but note that the command will look a bit funny because of the multiple @ signs:

$ ssh john@ad1.example.com@10.51.0.11 Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-24-generic x86_64) (. ) Last login: Thu Apr 16 21:22:55 2020 john@ad1.example.com@ad-client:~$ 

Note

In the ssh example, public key authentication was used, so no password was required. Remember that ssh password authentication is by default disabled in /etc/ssh/sshd_config .

Kerberos Tickets

If you install krb5-user , your AD users will also get a kerberos ticket upon logging in:

john@ad1.example.com@ad-client:~$ klist Ticket cache: FILE:/tmp/krb5cc_1725801106_9UxVIz Default principal: john@AD1.EXAMPLE.COM Valid starting Expires Service principal 04/16/20 21:32:12 04/17/20 07:32:12 krbtgt/AD1.EXAMPLE.COM@AD1.EXAMPLE.COM renew until 04/17/20 21:32:12 

Note

realm also configured /etc/krb5.conf for you, so there should be no further configuration prompts when installing krb5-user

Let’s test with smbclient using kerberos authentication to list he shares of the domain controller:

john@ad1.example.com@ad-client:~$ smbclient -k -L server1.ad1.example.com Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share IPC$ IPC Remote IPC NETLOGON Disk Logon server share SYSVOL Disk Logon server share SMB1 disabled -- no workgroup available 

Notice how we now have a ticket for the cifs service, which was used for the share list above:

john@ad1.example.com@ad-client:~$ klist Ticket cache: FILE:/tmp/krb5cc_1725801106_9UxVIz Default principal: john@AD1.EXAMPLE.COM Valid starting Expires Service principal 04/16/20 21:32:12 04/17/20 07:32:12 krbtgt/AD1.EXAMPLE.COM@AD1.EXAMPLE.COM renew until 04/17/20 21:32:12 04/16/20 21:32:21 04/17/20 07:32:12 cifs/server1.ad1.example.com@AD1.EXAMPLE.COM 

Desktop Ubuntu Authentication

The desktop login only shows local users in the list to pick from, and that’s on purpose.

To login with an Active Directory user for the first time, follow these steps:

Known Issues

When logging in on a system joined with an Active Directory domain, sssd (the package responsible for this integration) will try to apply Group Policies by default. There are cases where if a specific policy is missing, the login will be denied.
This is being tracked in bug #1934997. Until the fix becomes available, please see comment #5 in that bug report for existing workarounds.

Resources

Источник

Настройка SSH на CentOS с аутентификацией через Active Directory

Обновлено: 27.10.2020 Опубликовано: 2016 год или раньше

Используемые термины: SSH, Active Directory, CentOS. Мы рассмотрим простые примеры команд, которые позволят настроить аутентификацию пользователей Active Directory на Linux для входа по SSH. Данная инструкция подойдет для CentOS версий 7 и 8.

Подготовка сервера

Настройка аутентификации SSH через AD

• realmd — сервис для автоматического поиска и конфигурирования AD.
• sssd — пакет программ, с помощью которого можно настраивать аутентификацию и авторизацию в системах на базе UNIX.
• oddjob — служба, которая принимает запросы по D-BUS (системная шина сообщений) на выполнение действий.
• oddjob-mkhomedir — в соответствии с названием, пакет позволяет отправить запрос на создание домашнего каталога пользователя.
• adcli — утилита для ввода компьютера в домен.
• samba-common и samba-common-tools — набор пакетов для выполнения запросов к файлам и принтерам клиентов Microsoft Windows.

realm discover DOMAIN.LOCAL

realm join -U username DOMAIN.LOCAL

* DOMAIN.LOCAL — ваш домен.
** username — имя учетной записи с правом вводить компьютер в домен.

Настраиваем sssd для возможности вводить логин без префикса домена:

Разрешаем создавать домашние директории новым пользователям:

authconfig —enablemkhomedir —enablesssdauth —updateall

systemctl enable sssd.service

Готово. Пробуем зайти по SSH под доменной учетной записью.

Аутентификация по группам AD

Мы настроили возможность авторизовываться в системе для любого пользователя в Active Directory. Попробуем ограничить доступ с помощью групп безопасности.

Мы можем задать настройки в конфигурационном файле:

simple_allow_groups = Domain Admins@domain.local

* где в данном примере предоставлен доступ все пользователям группы Domain Admins.

После внесения изменений нужно перезагрузить сервис sssd:

Также мы можем управлять настройками командами.

Теперь дадим разрешение для 3-х групп:

realm permit -g «Domain Admins»@domain.local

realm permit -g «Тестовая группа»@domain.local

realm permit -g ssh@domain.local

* данные команды разрешают вход пользователям групп Domain Admins, Тестовая группа, ssh.

Источник