Мы пытаемся настроить сервер Active Directory для проверки подлинности в масштабах компании.
Некоторые из серверов, которые должны аутентифицироваться по AD, помещены в DMZ, поэтому мы подумали об использовании LDAP-сервера в качестве прокси, так что только 1 сервер в DMZ должен подключаться к локальной сети, где размещен AD-сервер. ).
При некотором поиске в Google не возникло проблем с настройкой slapd (см. Slapd.conf ниже), и, похоже, он работал при использовании инструмента ldapsearch, поэтому мы попытались использовать его в apache2 htaccess для аутентификации пользователя через LDAP-прокси.
И здесь возникает проблема: мы обнаружили, что имя пользователя в AD хранится в атрибуте sAMAccountName, поэтому мы настроили его в .htaccess (см. Ниже), но логин не работал.
В системном журнале мы выяснили, что фильтра для ldapsearch не было (как и должно быть) '(& (objectClass = *) (sAMAccountName = authtest01))' но '(& (objectClass = *) (? = не определено))'который мы выяснили, это способ slapd показать, что атрибут не существует или значение этого атрибута синтаксически неверно.
Мы подумали об отсутствующей схеме и нашли microsoft.schema (и .std / .ext из них) и попытался включить их в slapd.conf. Что не работает. Мы не нашли рабочих схем, поэтому мы просто выбрали часть, касающуюся sAMAccountName, и построили microsoft.minimal.schema (см. Ниже), которую мы включили. Теперь мы получаем более точный лог в системном журнале:
Jun 16 13:32:04 breauthsrv01 slapd[21229]: get_ava: illegal value for attributeType sAMAccountName
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SRCH base="ou=xxx,dc=int,dc=xxx,dc=de" scope=2 deref=3 filter="(&(objectClass=\*)(?sAMAccountName=authtest01))"
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SRCH attr=sAMAccountName
Jun 16 13:32:04 breauthsrv01 slapd[21229]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Однако использование нашего Apache htaccess напрямую с AD через LDAP работает. У кого-нибудь есть рабочая установка? Спасибо за любую помощь заранее:
slapd.conf:
allow bind_v2
include /etc/ldap/schema/core.schema
...
include /etc/ldap/schema/microsoft.minimal.schema
...
backend ldap
database ldap
suffix "ou=xxx,dc=int,dc=xxx,dc=de"
uri "ldap://80.156.177.161:389"
acl-bind bindmethod=simple binddn="CN=authtest01,ou=GPO-Test,ou=xxx,dc=int,dc=xxx,dc=de" credentials=xxxxx
.htaccess:
AuthBasicProvider ldap
AuthType basic
AuthName "AuthTest"
AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?sAMAccountName?sub"
AuthzLDAPAuthoritative On
AuthLDAPGroupAttribute member
AuthLDAPBindDN CN=authtest02,OU=GPO-Test,OU=xxx,DC=int,DC=xxx,DC=de
AuthLDAPBindPassword test123
Require valid-user
microsoft.minimal.schema:
attributetype ( 1.2.840.113556.1.4.221
NAME 'sAMAccountName'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )
Вам нужно добавить сопоставления в ваш файл slapd.conf:
moduleload rwm
...
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map objectClass posixGroup group
rwm-map objectClass posixAccount person
rwm-map objectClass memberUid member
Затем вы можете искать uid атрибут вместо sAMAccountName атрибут в вашем файле .htaccess:
AuthLDAPURL "ldap://breauthsrv01.xxx.de:389/OU=xxx,DC=int,DC=xxx,DC=de?uid?sub"
Ответ Джонатана указал мне правильное направление, помогая преодолеть:
additional info: sAMAccountName: attribute type undefined
проблема. Но я понял, что вам нужно определить этот атрибут как юридическое значение для записи человека, и вам нужно дать каждому человеку objectClass, которому разрешено иметь этот атрибут. Как и все атрибуты, вы можете дать inetOrgPerson.
Мой файл microsoft.minimal.schema теперь:
attributetype ( 1.2.840.113556.1.4.221
NAME 'sAMAccountName'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )
attributetype ( 1.2.840.113556.1.4.146
NAME 'objectSid'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.40'
SINGLE-VALUE )
objectclass ( 1.2.840.113556.1.5.6
NAME 'securityPrincipal'
SUP top
AUXILIARY
MUST (objectSid $ sAMAccountName )
MAY () )
# MAY (nTSecurityDescriptor $ securityIdentifier $ supplementalCredentials $
# rid $ sAMAccountType $ sIDHistory $ altSecurityIdentities $ tokenGroups $
# tokenGroupsNoGCAcceptable $ accountNameHistory $
# tokenGroupsGlobalAndUniversal))
Я ничего не заменяю необязательные атрибуты MS, поэтому мне не нужно их определять.
Пример записи пользователя выглядит так:
dn: uid=user2,ou=example,dc=aa,dc=ad,dc=example,dc=gov
uid: user2
sAMAccountName: user2
objectSid: user2
cn: User Two
displayName: User Two
givenName: User2
sn: One
objectClass: inetOrgPerson
objectClass: securityPrincipal
mail: user2@example.gov
# password from slappasswd is 'user2'
userPassword: {SSHA}sjB5fmIIPTrUUammtmonP+6DdC93+P4L
Вы видите это сообщение об ошибке:
get_ava: недопустимое значение для attributeType sAMAccountName
Это вызвано вашим определением sAMAccountName атрибут в microsoft.minimal.schema не хватает правила сопоставления. Проще говоря, определения схемы OpenLDAP позволяют вам указать, какие виды поиска разрешены (наличие, точное совпадение, совпадение подстроки и т. Д.), А в этом определении их нет.
Попробуй это:
attributetype ( 1.2.840.113556.1.4.221
NAME 'sAMAccountName'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )