Skip to content

Document Header

Настройка OpenVpn с доменной авторизацией Samba 4 через ldap auth

Настройка OpenVpn с доменной авторизацией Samba 4 через ldap auth published on Комментариев к записи Настройка OpenVpn с доменной авторизацией Samba 4 через ldap auth нет

Настройка OpenVpn с доменной авторизацией в Samba 4 server AD DC через ldap auth.

Предполагается, что у вас установлена и настроена samba 4 server в режиме контроллера домена active directory.
Установлен openvpn с поддержкой ldap. В моей системе он шел отдельным пакетом openvpn-auth-ldap
В active directory существует обычный (без привелегий) пользователь ldapuser и группа openvpn, в которую добавлены пользователи, которые будут получать доступ через openvpn.
192.168.5.0 – физическая подсеть
192.168.7.0 – виртуальная подсеть

Создадим сертификаты при помощи скриптов easy-rsa. У меня они находятся в /etc/openvpn/easy-rsa так же они могут быть в /usr/share/doc/openvpn. Если у вас их нет, их можно взять здесь.

Создадим директорию для ключей:

# mkdir /etc/openvpn/keys

Загрузим переменные в оболочку:

# cd /etc/openvpn/easy-rsa/2.0/
# . ./vars

Запустим скрипт для создания серийного и индексного файла для новых ключей:

# ./clean-all

Создадим корневой сертификат.

# ./build-ca

Создадим сертификат для сервера.

# ./build-key-server server

Создадим ключ Диффи Хельман:

# ./build-dh

Создадим ключ для tls-аутентификации:

# openvpn --genkey –secret ta.key

Скопируем все ключи ca.crt, dh1024.pem, server.crt, server.key, ta.key из /etc/openvpn/easy-rsa/2.0/keys/ в /etc/openvpn/keys/

Создадим основной конфигурационный файл /etc/openvpn/server.conf

plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-ldap.so "/etc/openvpn/ldap.conf" #подгружаем плагин и конфигурационный файл для него.
proto udp # tcp/udp, рекомендуется udp, так как более «легкий» протокол.
dev tap # тип интерфейса tun/tap
port 5050
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
client-cert-not-required #без клиентского сертификата, будем использовать ldap-авторизацию.
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
server 192.168.7.0 255.255.255.0
push "route 192.168.5.0 255.255.255.0"
route 192.168.7.0 255.255.255.252
tls-server
tls-auth /etc/openvpn/keys/ta.key 0
tls-timeout 120
persist-key
persist-tun
route-gateway 192.168.7.1
push "route-gateway 192.168.7.1"
keepalive 10 120
comp-lzo
max-clients 30
client-to-client
verb 3
user openvpn
group openvpn
status /var/log/openvpn-status.log
log /var/log/openvpn.log
auth MD5
cipher BF-CBC

Создадим конфигурационный файл для ldap-авторизации /etc/openvpn/ldap.conf

<LDAP>

URL        ldap://127.0.0.1 #адрес ldap-сервера samba 4
BindDN        cn=ldapuser,cn=Users,dc=test,dc=loc #Существующий обычный (без привелегий) пользователь от которого будем производить поиск в LDAP
Password    User_123 #пароль пользователя для поиска в ldap-каталоге.
Timeout        15
TLSEnable    no
FollowReferrals yes
TLSCACertDir    /etc/ssl/certs

</LDAP>
<Authorization>

BaseDN        «cn=Users,dc=test,dc=loc»
SearchFilter    «(&(sAMAccountname=%u)(objectClass=user)(memberOf=cn=openvpn,cn=Users,dc=test,dc=loc))» #Правило фильтра, по которому будет осуществляться поиск, а при совпадении правила и авторизация. Логика фильтра такая же как в proftpd. Более подробно можно почитать здесь.
RequireGroup    false #Штатная возможность проверки пользователя в группе. Не использовал, потому что пока не придумал как запросить пользователя через MemberAttribute.
<Group>

BaseDN        «cn=Users,dc=test,dc=loc»
SearchFilter    «(|(cn=openvpn))»
MemberAttribute    member

</Group>

</Authorization>

Настройка windows-клиента
Скачаем клиента.
При установке будем использовать путь по умолчанию.

После установки скопируем с сервера ca.crt ta.key из /etc/openvpn/keys на клиента в директорию C:Program FilesOpenVPNconfigtest_loc

Создадим файл конфигурации C:Program FilesOpenVPNconfigtest_loc.ovpn

auth-user-pass
remote 192.168.5.50 #адрес нашего vpn-сервера
proto udp
dev tap
port 5050
client
resolv-retry infinite
ca test_loc/ca.crt
tls-auth test_loc/ta.key 1
auth MD5
cipher BF-CBC
ns-cert-type server
persist-key
persist-tun
comp-lzo

Запускаем сервер openvpn, подключаемся клиентом.

openvpn client connect

Настройка Proftpd для Samba 4 через auth mod_ldap.

Настройка Proftpd для Samba 4 через auth mod_ldap. published on Комментариев к записи Настройка Proftpd для Samba 4 через auth mod_ldap. нет

Настройка Proftpd для Samba 4 server в режиме domain controller через ldap.

Предполагается, что у вас установлена и настроена samba 4 server в режиме active directory domain controller.
Установлен proftpd с поддержкой ldap.

В AD созданы 3 пользователя:
1. ldap_user – обычный (без привелегий) пользователь от которого будем производить поиск в LDAP с паролем User_123
2. user1
3. user2
В AD созданы 2 группы ftp1 и ftp2.
2 группы нам понадобятся исключительно для наглядной иллюстрации работы фильтра. В реальной ситуации достаточно 1-ой.
user1 входит в обе группы (ftp1 и ftp2)
user2 только в одну из них, допустим только в ftp1
Domain name: test.loc
Hostname: pdc.test.loc
На файловой системе создана директория /share/ftp

Заглянем в /etc/proftpd.conf изменим/добавим необходимые для нашей задачи строки:

LoadModule mod_ldap.c      # подгружаем модуль LDAP

RequireValidShell no      # пока не отменил данную проверку shell, proftpd отказывался меня авторизовывать.

# Use pam to authenticate (default) and be authoritative
AuthPAMConfig            proftpd
#AuthOrder            mod_auth_pam.c* mod_auth_unix.c
AuthOrder            mod_ldap.c       # добавляем авторизацию через ldap
PersistentPasswd        off

# Use this to excude users from the chroot
#DefaultRoot            ~ !adm
DefaultRoot            /share/ftp/%u      # Помещение пользователя в chroot. Ограничение корневого уровня, выше которого пользователь не сможет подняться. В данном случае пользователь имеет возможность находиться только в пределах своей директории (homedir).

#<IfModule mod_ldap.c>      # 2-ой способ подгрузки модуля. В моей версии не заработал.
LDAPServer "pdc.test.loc"      # адрес нашего LDAP сервера.
LDAPAttr uid SAMAccountname      # LDAP атрибут
LDAPDNInfo "cn=ldap_user,cn=Users,dc=test,dc=loc"  "User_123"      #Существующий обычный (без привелегий) пользователь от которого будем производить поиск в LDAP
LDAPAuthBinds on
LDAPDoAuth on "cn=Users,dc=test,dc=loc" (&(sAMAccountname=%u)(objectClass=user)(memberOf=cn=ftp1,cn=users,dc=test,dc=loc)(memberOf=cn=ftp2,cn=users,dc=test,dc=loc))      #Наш «боевой» фильтр, в котором указано, что доступ к ftp получит только тот пользователь, который будет входить в обе группы ftp1 и ftp2. Фильтр ищет совпадение всех вышеперечисленных полей в LDAP (objectclass=значение)(memberOf=значение)(memberOf=значение). Если какого-то поля для пользователя не существует, например, потому, что он не является членом группы, то совпадения не будет, а, следовательно, в доступе будет отказано.
#LDAPDoAuth on "cn=Users,dc=test,dc=loc" (&(sAMAccountname=%u)(objectClass=top)(ObjectCategory=user)(objectclass=person))      #Еще один пример фильтра, который предоставит доступ к ftp любому существующему пользователю домена.
LDAPdoUIDLookups on "cn=Users,dc=test,dc=loc"
LDAPdoGIDLookups on "cn=Groups,dc=test,dc=loc"
LDAPDefaultUID 99     # Можно использовать любой UID, однако пока гуглил встретил описание «глюка» с upload файлов при UID 10000. Для своих целей взял nobody.
LDAPDefaultGID 99     # Можно так же использовать любой GID. Для своих целей взял nobody.
LDAPGenerateHomedir on      #Создать homedir для пользователя
LDAPForceGeneratedHomedir on      #Принудительно создать homedir для пользователя
LDAPGenerateHomedirPrefix /share/ftp      #Префикс для homedir
#</IfModule>

# TLS      #Включаем TLS.
# Explained at http://www.castaglia.org/proftpd/modules/mod_tls.html
TLSEngine            on
TLSRequired            off
TLSRSACertificateFile        /etc/pki/tls/certs/proftpd.pem
TLSRSACertificateKeyFile    /etc/pki/tls/certs/proftpd.pem
#TLSCipherSuite            ALL:!ADH:!DES
TLSOptions            NoCertRequest
TLSVerifyClient        off
#TLSRenegotiate        ctrl 3600 data 512000 required off timeout 300
TLSLog                /var/log/proftpd/tls.log
TLSProtocol SSLv23

<Directory /share/ftp*>      #Описание нашей директории
AllowOverwrite        yes
<Limit ALL>
AllowAll
</Limit>

<Limit ALL SITE_CHMOD>
AllowAll
</Limit>
</Directory>

Не знаю насколько понятно объяснил про механизм работы фильтра. Для того, чтобы снять любые вопросы запустим из консоли следующую команду:

#ldapsearch -h localhost -W -x -D "cn=ldap_user,cn=Users,dc=test,dc=loc" -b "cn=Users,dc=test,dc=loc" sAMAccountName= user1
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <cn=Users,dc=test,dc=loc> with scope subtree
# filter: sAMAccountName=user1
# requesting: ALL
#

# user1, Users, test.loc
dn: CN=user1,CN=Users,DC=test,DC=loc
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: user1
givenName: user1
instanceType: 4
whenCreated: 20130410135259.0Z
displayName: user1
uSNCreated: 5271
name: user1
objectGUID:: *****************
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid:: ********************************
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: user1
sAMAccountType: 805306368
userPrincipalName: user1@test.loc
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=test,DC=loc
userAccountControl: 66048
pwdLastSet: 130101055070000000
whenChanged: 20130410221147.0Z
uSNChanged: 5276
memberOf: CN=ftp1,CN=Users,DC=test,DC=loc
memberOf: CN=ftp2,CN=Users,DC=test,DC=loc
distinguishedName: CN=user1,CN=Users,DC=test,DC=loc

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Как вы видите мы могли бы использовать для фильтра и другие поля. Например, вместо (objectclass=person) мы с тем же успехом могли использовать (objectClass=organizationalPerson) ну или (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=test,DC=loc)

Как я уже и говорил выше данный пользователь является членом 2-ух групп. Все поля запроса совпадают, поэтому доступ будет получен.

Теперь сделаем запрос из консоли для 2-ого пользователя user2:

#ldapsearch -h localhost -W -x -D "cn=ldap_user,cn=Users,dc=test,dc=loc" -b "cn=Users,dc=test,dc=loc" sAMAccountName= user2
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <cn=Users,dc=test,dc=loc> with scope subtree
# filter: sAMAccountName=user2
# requesting: ALL
#

# user2, Users, test.loc
dn: CN=user2,CN=Users,DC=test,DC=loc
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: user2
givenName: user2
instanceType: 4
whenCreated: 20130509035833.0Z
displayName: user2
uSNCreated: 5297
name: user2
objectGUID:: ********************
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid:: *******************************
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: user2
sAMAccountType: 805306368
userPrincipalName: user2@test.loc
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=test,DC=loc
pwdLastSet: 130125455140000000
userAccountControl: 66048
whenChanged: 20130509035835.0Z
uSNChanged: 5300
memberOf: CN=ftp1,CN=Users,DC=test,DC=loc
distinguishedName: CN=user2,CN=Users,DC=test,DC=loc

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Здесь мы видим, что пользователь входит только в одну группу, следовательно по шаблону (memberOf=CN=ftp2,CN=Users,DC=test,DC=loc) совпадения не будет, и пользователь доступ не получит. Если убрать эту запись из фильтра, то оба пользователя начнут получать доступ.

Настройка закончена. Теперь можно запускать proftpd и проверять работоспособность.

Для поиска проблем, можно запускать proftpd в режиме отладки с достаточным уровнем сообщений. Максимальный 10. Мне это помогло понять в каком месте конфигурационного файла я ошибся. Команда:

#proftpd --nodaemon --debug=10