☰

mod_authnz_ldap: Использование userPrincipalName и sAMAccountName с AuthzSVNAccessFile

tag-icon • tag-icon svn apache2 mod-auth-ldap
mod_authnz_ldap: Использование userPrincipalName и sAMAccountName с AuthzSVNAccessFile

Это мой первый пост здесь, поэтому, пожалуйста, будьте со мной любезны...

У нас есть Apache, управляющий доступом к нашему серверу subversion. В настоящее время пользователи могут входить только с помощью своего sAMAccountName, но поскольку userPrincipalName (адрес электронной почты) постепенно становится основным идентификатором для большинства входов, мы хотели бы поддерживать его, а также сохранить поддержку sAMAccountName.

Текущий подход, который выглядит следующим образом, имеет тот недостаток, что оба имени пользователя — sAMAccountName и userPrincipalName — должны быть указаны в файле svnaccess:

<AuthnProviderAlias ldap ldap-sAMAccountName>
    AuthLDAPBindDN "CN=d-svn-ldap,OU=IT-050,OU=Service Accounts,OU=Accounts,OU=Domain Administration,DC=cds,DC=company"
    AuthLDAPBindPassword ***
    AuthLDAPUrl "ldap://server.company:3268/DC=cds,DC=company?sAMAccountName?sub?(objectclass=user)"
</AuthnProviderAlias>
<AuthnProviderAlias ldap ldap-userprincipalname>
    AuthLDAPBindDN "CN=d-svn-ldap,OU=IT-050,OU=Service Accounts,OU=Accounts,OU=Domain Administration,DC=cds,DC=company"
    AuthLDAPBindPassword ***
    AuthLDAPUrl "ldap://server.company:3268/DC=cds,DC=company?userPrincipalName?sub?(objectclass=user)"
</AuthnProviderAlias>

<Location "/our_repo">
DAV svn
SVNPath /svn/repos/our_repo
SVNListParentPath on

AuthzSVNAccessFile /etc/apache2/conf-available/authz_repository_our_repo
Options Indexes Followsymlinks

AuthBasicProvider ldap-sAMAccountName  ldap-userprincipalname

AuthType Basic
AuthName "LDAP authentication"
Require valid-user
# Note that Require ldap-* would not work here, since the
# AuthnProviderAlias does not provide the config to authorization providers
# that are implemented in the same module as the authentication provider.
</Location>

Поэтому я ищу способ указать только userPrincipalNames в svnaccessfile. Я надеялся, что AuthLDAPRemoteUserAttribute может помочь здесь, поэтому я добавил AuthLDAPRemoteUserAttribute userPrincipalNameв ldap-sAMAccountName, что привело к такому сообщению в error.log:

auth_ldap authenticate: REMOTE_USER должен был быть установлен с атрибутом 'userPrincipalName', но этот атрибут не был запрошен в запросе LDAP для пользователя. REMOTE_USER вернется к имени пользователя или DN в зависимости от ситуации.

Правильный ли это подход? Возможно ли это вообще?

Спасибо

Фло

решение1

Вдохновленhttps://svn.haxx.se/users/archive-2010-04/0011.shtmlмы попробовали еще раз и нашли решение, как запросить ldap для двух полей:

<AuthnProviderAlias ldap ldap-sAMAccountName>
    AuthLDAPBindDN "CN=d-svn-ldap,OU=IT-050,OU=Service Accounts,OU=Accounts,OU=Domain Administration,DC=cds,DC=company"
    AuthLDAPBindPassword ***
    AuthLDAPRemoteUserIsDN on
    AuthLDAPUrl "ldap://server.company:3268/DC=cds,DC=company?sAMAccountName,userPrincipalName?sub?(objectclass=*)"
    AuthLDAPRemoteUserAttribute userPrincipalName
</AuthnProviderAlias>

Последняя строка превращает REMOTE_USER в содержимое userPrincipalName.

Поскольку userPrincipalName в нашей компании содержит адреса электронной почты с некоторыми заглавными буквами, нам приходится использовать точно такой же регистр адресов электронной почты в файле svnaccess.

Чтобы использовать только userPrincipalName, а не то, что ввел пользователь (REMOTE_USER), нам также пришлось указать AuthLDAPRemoteUserAttribute для другого AutnProviderAlias:

<AuthnProviderAlias ldap ldap-userprincipalname>
    AuthLDAPBindDN "CN=d-svn-ldap,OU=IT-050,OU=Service Accounts,OU=Accounts,OU=Domain Administration,DC=cds,DC=company"
    AuthLDAPBindPassword ***
    AuthLDAPUrl "ldap://server.company:3268/DC=cds,DC=company?userPrincipalName?sub?(objectclass=user)"
    AuthLDAPRemoteUserAttribute userPrincipalName
</AuthnProviderAlias>

Нам также пришлось изменить порядок поставщиков:

AuthBasicProvider ldap-userprincipalname ldap-sAMAccountName

Побочные уведомления: error.log показывает только отклонения из-за результатов ldap, отсутствующие разрешения в svnaccessfile там не отображаются. Поэтому изменения в svn accessfile видны без перезапуска apache или удаления входа в браузер.

Связанный контент