Проверка компьютер домен linux

Вики IT-KB

Утилита ldapsearch (клиент OpenLDAP) и проверка подключения к контроллеру домена Active Directory

Проверку выполняем на примере Debian GNU/Linux 8 (Jessie). Сначала убедимся в том, что клиент OpenLDAP установлен в системе:

ii ldap-utils 2.4.40+dfsg-1+deb8u2 amd64 OpenLDAP utilities ii libldap-2.4-2:amd64 2.4.40+dfsg-1+deb8u2 amd64 OpenLDAP libraries

Исходные данные для проверки подключения клиента OpenLDAP к LDAP-каталогу на примере контроллера домена Active Directory (AD):

s-LDAP-Check-User — Имя пользователь в домене AD, от имени которого выполняется подключение (уровень прав в домене — рядовой пользователь);

«OU=Test Users,OU=KOM,DC=ad,DC=holding,DC=com» — DN-имя контейнера в AD, в котором выполняется поиск пользователя Test-User.

Проверка подключения по протоколу LDAP (TCP 389)

Используется подключение типа ldap:/. Учётные данные пользователя s-LDAP-Check-User передаются по сети в открытом виде:

$ ldapsearch -v -x \ -D "s-LDAP-Check-User@ad.holding.com" -w "PaZsw0rd" \ -b "OU=Test Users,OU=KOM,DC=ad,DC=holding,DC=com" \ -H "ldap://dc01.ad.holding.com" sAMAccountName=Test-User

Проверка подключения по протоколу LDAPS (TCP 636)

Используется подключение типа ldaps:/. LDAP-сессия шифруется с помощью SSL-сертификата, предоставляемого контроллером домена. Чтобы LDAP-клиент доверял сертификату контроллера домена, нам нужно создать файл, содержащий корневые сертификаты доменных Центров сертификации, которыми подписан сертификат контроллера домена. Назовём этот файл, например /etc/ssl/certs/cacerts.pem, и скопируем в него корневые сертификаты доменных ЦС в формате PEM и кодировке Base-64.

Изменим на время проверки конфигурационный файл клиента OpenLDAP /etc/ldap/ldap.conf, указав в переменной TLS_CACERT путь к созданному нами файлу с корневыми сертификатами доменных ЦС:

. #TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_CACERT /etc/ssl/certs/cacerts.pem .

После этого можно попробовать выполнить поиск по протоколу LDAPS:

$ ldapsearch -v -x \ -D "s-LDAP-Check-User@ad.holding.com" -w "PaZsw0rd" \ -b "OU=Test Users,OU=KOM,DC=ad,DC=holding,DC=com" \ -H "ldaps://dc01.ad.holding.com" sAMAccountName=Test-User

Проверка подключения по протоколу LDAP с защитой StartTLS (TCP 389)

Используется подключение типа ldap:/ с дополнительными ключами, включающими TLS : -Z и -ZZ. LDAP-сессия также шифруется с помощью SSL-сертификата, предоставляемого контроллером домена. Первичное подключение к контроллеру домена AD происходит по порту 389, затем создаётся отдельный защищённый TLS-туннель, внутри которого и происходит весь LDAP-обмен между клиентом и сервером. Используется настроенный нами ранее файл корневых сертификатов доменных ЦС.

$ ldapsearch -Z -v -x \ -D "s-LDAP-Check-User@ad.holding.com" -w "PaZsw0rd" \ -b "OU=Test Users,OU=KOM,DC=ad,DC=holding,DC=com" \ -H "ldap://dc01.ad.holding.com" sAMAccountName=Test-User

Автор первичной редакции:
Алексей Максимов
Время публикации: 19.03.2017 18:04

Обсуждение

unix-linux/linux-cli-tools/openldap-ldap-client-check-connection-to-active-directory-domain-controller-with-ldapsearch.txt · Последнее изменение: 19.03.2017 19:05 — Алексей Максимов

Источник

Демонстрация включения Ubuntu в домен

В прошлой заметке я описывал процедуру включения ОС Ubuntu в состав домена Windows. Теперь приведу наглядные примеры, как можно проверить работоспособность того, подключился ли компьютер к домену или нет.

Проверям, можем ли мы обращаться к компьютерам в домен по их имени:

ping fileserver.myserver.com -c 10 PING fileserver.myserver.com (172.17.1.6) 56(84) bytes of data. 64 bytes from fileserver.myserver.com (172.17.1.6): icmp_req=1 ttl=128 time=71.3 ms . 64 bytes from fileserver.myserver.com (172.17.1.6): icmp_req=9 ttl=128 time=1.65 ms 64 bytes from fileserver.myserver.com (172.17.1.6): icmp_req=10 ttl=128 time=4.25 ms

--- fileserver.myserver.com ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 1.494/9.540/71.321/20.673 ms

Проверяем, можем ли мы авторизироваться в домене. Выбираем какую-нибудь учетную запись в домене из Active Directory, и вводим от нее пароль, как показано ниже. Если после ввода пароля в консоли ничего не появилось, значит все прошло успешно.

kinit Ivanov@MYSERVER.COM
Password for Ivanov@MYSERVER.COM:

Чтобы окончательно убедиться в том, что все нормально и билет Kerberos для авторизации получен, введем следующую команду:

Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: Ivanov@MYSERVER.COM

Valid starting Expires Service principal 06/18/11 14:40:29 06/19/11 00:38:38 krbtgt/MYSERVER.COM@MYSERVER.COM renew until 06/19/11 14:40:29

Входим в домен (в пример от учетной записи администратора):

sudo net ads join -U Администратор -D MYSERVER.COM
Enter Администратор’s password:

Если на консоль выводится следующее, то вход в домен осуществлен успешно:

Using short domain name — MYSERVER
Joined ‘LAPTOPUBUNTU’ to realm ‘myserver.com’

Проверяем, что Winbind видит группы (-g) и пользователей (-u):

LAPTOPUBUNTU\nobody LAPTOPUBUNTU\myuser администратор krbtgt гость user_admin ivanov senatorov dholme jfine bmayer bmorelend myuser krayner mitchell

компьютеры домена издатели сертификатов пользователи домена гости домена серверы ras и ias администраторы домена администраторы схемы администраторы предприятия владельцы-создатели групповой политики группа с разрешением репликации паролей rodc группа с запрещением репликации паролей rodc контроллеры домена предприятия - только чтение контроллеры домена - только чтение контроллеры домена dnsadmins dnsupdateproxy финансы финансовые менеджеры продажи администраторы windows справка app_office 2007 пользователи dhcp администраторы dhcp

Проверяем, что Ubuntu запрашивает у Winbind информацию (содержимое файла /etc/passwd) о пользователях и группах:

root:x:0:0:root:/root:/bin/bash . ntp:x:113:124::/home/ntp:/bin/false администратор:*:10000:10000:Администратор:/home/MYSERVER/администратор:/bin/bash krbtgt:*:10001:10000:krbtgt:/home/MYSERVER/krbtgt:/bin/bash гость:*:10002:10001:Гость:/home/MYSERVER/гость:/bin/bash myuser_admin:*:10003:10000:Александр:/home/MYSERVER/user_admin:/bin/bash lapshenkov:*:10004:10000:Anton Ivanov:/home/MYSERVER/ivanov:/bin/bash senatorov:*:10005:10000:Alexander Petrov:/home/MYSERVER/ptrov:/bin/bash dholme:*:10006:10000:Дэн Холме:/home/MYSERVER/dholme:/bin/bash jfine:*:10007:10000:Джеймс Файн:/home/MYSERVER/jfine:/bin/bash bmayer:*:10008:10000:Барбара Майер:/home/MYSERVER/bmayer:/bin/bash bmorelend:*:10009:10000:Барбара Морленд:/home/MYSERVER/bmorelend:/bin/bash myuser:*:10010:10000:Александр:/home/MYSERVER/user:/bin/bash krayner:*:10011:10000:Тони Крайнер:/home/MYSERVER/krayner:/bin/bash mitchell:*:10012:10000:Скотт Митчелл:/home/MYSERVER/mitchell:/bin/bash getent group

root:x:0: . sambashare:x:122:myuser winbindd_priv:x:123: ntp:x:124: компьютеры домена:x:10002: издатели сертификатов:x:10003: пользователи домена:x:10000: гости домена:x:10001: серверы ras и ias:x:10004: администраторы домена:x:10005:user_admin,администратор администраторы схемы:x:10006:администратор администраторы предприятия:x:10007:администратор владельцы-создатели групповой политики:x:10008:администратор группа с разрешением репликации паролей rodc:x:10009: группа с запрещением репликации паролей rodc:x:10010:krbtgt контроллеры домена предприятия - только чтение:x:10011: контроллеры домена - только чтение:x:10012: контроллеры домена:x:10013: dnsadmins:x:10014: dnsupdateproxy:x:10015: финансы:x:10016: финансовые менеджеры:x:10017: продажи:x:10018: администраторы windows:x:10019: справка:x:10020:bmayer app_office 2007:x:10021:laptop$ пользователи dhcp:x:10024: администраторы dhcp:x:10025:

Как видно из приведенных примеров, все работает, как и должно быть.

Источник