Como autenticar usuários em grupos aninhados no Apache LDAP?

Question

Estou trabalhando com autenticação LDAP com a seguinte configuração

 AuthName            "whatever"
 AuthType            Basic
 AuthBasicProvider   ldap
 AuthLDAPUrl         "ldap://server/OU=SBSUsers,OU=Users,OU=MyBusiness,DC=company,DC=local?sAMAccountName?sub?(objectClass=*)"
 Require ldap-group  CN=MySpecificGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local

Isso funciona, no entanto eu tenho que colocar todos os usuários que eu quero autenticar em MySpecificGroup . Mas no servidor LDAP eu configurei que MySpecificGroup também contém o grupo MyOtherGroup com outra lista de usuários.

Mas esses usuários em MyOtherGroup não são autenticados, eu tenho que adicioná-los manualmente a MySpecificGroup e basicamente não posso usar o agrupamento aninhado. Estou usando o Windows SBS 2003.

Existe uma maneira de configurar o Apache LDAP para fazer isso? Ou há um problema com possível recursão infinita e, portanto, não é permitido?

    

Answer 1

Você precisa definir AuthLDAPSubGroupDepth para fazer isso funcionar. O inteiro que você fornece aqui especifica a profundidade máxima de aninhamento do subgrupo que será avaliada antes que a pesquisa do usuário seja descontinuada.

Adicione isto à sua configuração:

AuthLDAPSubGroupDepth 1

Mais informações: aqui e aqui .

    

Answer 2

Além de AuthLDAPSubGroupDepth , que está disponível apenas no apache 2.4, é possível, ao usar o Microsoft AD LDAP, fazer autorização usando grupos aninhados usando a regra de correspondência LDAP_MATCHING_RULE_IN_CHAIN. Isso é muito mais rápido do que pesquisar subgrupos no cliente, porque é feito no servidor DC com menos consultas pela rede.

Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=Access to Apache,OU=My Organization Unit,DC=company,DC=com

A string 1.2.840.113556.1.4.1941 é um OID chamado LDAP_MATCHING_RULE_IN_CHAIN . Este OID é atribuído pela Microsoft para ser usado com sua implementação LDAP (parte do Active Directory). Você não pode usá-lo com outros servidores LDAP. O formato humano redeable é: iso(1).member_body(2).us(840).microsoft(113556).ad(1).as_schema(4).LDAP_MATCHING_RULE_IN_CHAIN(1941)

Da documentação da Microsoft:

This rule is limited to filters that apply to the DN. This is a special "extended" match operator that walks the chain of ancestry in objects all the way to the root until it finds a match.

Veja também:

• link
• link

Answer 3

Parece que sua única opção no Apache 2.2 é listar todos os grupos incluídos por seu grupo autorizado principal.

Require ldap-group  CN=MySpecificGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local
Require ldap-group  CN=MyOtherGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local

Isso deve ser razoável se seus grupos aninhados não forem muito complicados.

Cruzando domínios do AD (usando dois servidores LDAP)

Você pode configurar o OpenLDAP com a sobreposição de slapd_meta em execução no servidor da Web para fazer proxy de sua autenticação.

/etc/ldap/slapd.conf deve ser parecido com:

database meta
suffix   "DC=company,DC=local"
uri      "ldap://a.foo.com/OU=MyBusiness,DC=company,DC=local"
uri      "ldap://b.foo.com/OU=otherdomainsuffix,DC=company,DC=local"

Então, a sua estrofe mod_authnz_ldap seria algo como:

AuthName            "whatever"
AuthType            Basic
AuthBasicProvider   ldap
AuthLDAPUrl         "ldapi:///DC=company,DC=local?sAMAccountName?sub?(objectClass=*)"
Require ldap-group  CN=MySpecificGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local
Require ldap-group  CN=MyOtherGroup,OU=Security Groups,OU=otherdomainsuffix,DC=company,DC=local

Isso exigirá algumas massagens para que funcione, mas acho que essa é a ideia geral.

    

Answer 4

Embora a solução fornecida por @Mircea_Vutcovici tenha funcionado para mim, minha única crítica é que as pessoas podem ficar enjoadas quando veem operadores bit a bit em uso.

Por exemplo, entregarei uma instalação do Apache Bloodhound, que usa o Apache HTTPd como front-end com a autenticação do grupo do AD, para um grupo de desenvolvedores. Eles vão ter problemas em lidar com operadores bit a bit. Os administradores não serão tão melindrados, é claro ... espero.

Dito isso, eu tenho uma solução que não usa o operador bit a bit e que não usa várias definições do grupo ldap.

A seguinte configuração funciona para mim:

<Location /protected>
    # Using this to bind
    AuthLDAPURL "ldap://<MY_SERVER>:3268/<MY_SEARCH_BASE>?sAMAccountName?sub?(objectClass=user)"
    AuthLDAPBindDN "<MY_BIND_DN>"
    AuthLDAPBindPassword "<MY_PASSWORD>"
    LDAPReferrals Off

    AuthType Basic
    AuthName "USE YOUR AD ACCOUNT"
    AuthBasicProvider ldap
    Require ldap-group <MY_PARENT_GROUP>
    AuthLDAPMaxSubGroupDepth 1
    AuthLDAPSubgroupAttribute member
    AuthLDAPSubGroupClass group
    AuthLDAPGroupAttribute member
    AuthLDAPGroupAttributeIsDN on
</Location>

A parte crítica foi a seguinte configuração:

AuthLDAPSubGroupClass group

AuthLDAPMaxSubGroupDepth não funciona sozinho, nem quando associado ao AuthLDAPSubgroupAttribute. Foi somente quando eu usei AuthLDAPSubGroupClass que auth contra subgrupos começou a trabalhar ... pelo menos para mim e minha situação.