Esta seção descreve como configurar LDAP para proteger arquivos no IBM® HTTP Server.
Antes de Iniciar
Recurso Reprovado: O módulo mod_ibm_ldap é fornecido com esta liberação do IBM HTTP
Server para compatibilidade com as liberações anteriores. Se estiver usando o módulo mod_ibm_ldap para a configuração LDAP, você deverá migrar as configurações existentes para usar os módulos mod_authnz_ldap e mod_ldap para assegurar suporte futuro para a configuração LDAP. Consulte o tópico
Autenticando com LDAP no IBM HTTP Server usando mod_ldap para obter uma descrição de como usar o módulo mod_ldap.
depfeat
O
módulo LDAP não é carregado no IBM HTTP Server por padrão. Sem a diretiva LoadModule, os recursos do LDAP não ficam disponíveis para
uso. Para ativar a função LDAP, inclua uma diretiva LoadModule
no arquivo do IBM HTTP Server, httpd.conf,
conforme a seguir:
Se você tiver o cliente LDAP instalado em seu computador, será possível utilizar
ldapsearch como uma ferramenta para testar os valores que você pretende utilizar para
as várias configurações.
Sobre Esta Tarefa
Consulte Diretivas LDAP para obter descrições detalhadas das diretivas LDAP (mod_ibm_ldap).
Procedimento
- Edite o arquivo de configuração httpd.conf do IBM HTTP Server.
- Determine o recurso para o qual deseja limitar acesso. Por exemplo: <Directory "/secure_info">.
- Inclua diretivas em httpd.conf no local do
diretório (contêiner) a ser protegido com os valores específicos em seu ambiente. Exemplo:
- LdapConfigFile path_to_ldap.prop
- AuthType Basic
- AuthName "Title of your protected Realm"
- Require valid-user
- Há três opções para como usar o IBM HTTP
Server para autenticar-se com sua instalação de LDAP existente.
- Autorização baseada na associação de grupos LDAP.
Utilize o LDAP para
verificar as senhas do usuário e verificar se o usuário existe em um grupo definido no
LDAP.
Nota: A associação que identifica o usuário como sendo capaz de acessar
o recurso é uma parte do grupo, não parte da própria entrada LDAP do usuário.
Por exemplo,
para restringir o acesso a um grupo, inclua a seguinte diretiva:
LDAPRequire group grp1
Para
essa forma de LDAPRequire, é necessário ter grupos configurados em seu repositório LDAP
que estejam de acordo com as regras a seguir (utilizando o nome do grupo de exemplo grp1):
- Há uma entrada em seu repositório LDAP que corresponde ao filtro de procura
a seguir, em que os valores groupofnames e groupofuniquenames são
valores de exemplos especificados em ldap.group.dnattributes.
Nota: O valor apropriado
de ldap.group.dnattributes é uma lista de quais objectclasses signify é um grupo
em seu esquema LDAP.
ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
(objectclass=groupofuniquenames)))"
- Como parte da entrada LDAP para "grp1," há uma série de atributos
que correspondem aos seguintes, em que os valores member e uniquemember são
valores de exemplo de ldap.group.memberAttributes.
Nota: O valor apropriado de ldap.group.memberAttributes
é uma lista de quais objectclasses signify é uma associação em um grupo. Os valores
dessas entradas são DN (Distinguished Names) de seus usuários.
ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
(objectclass=groupofuniquenames)))" member uniquemember
Exemplo:
ldapsearch -x -h myldapserver -D cn=root -w rootpw
"(&(cn=grp1)(|(objectclass=groupofnames)(objectclass=groupofuniquenames)))"
member uniquemember
dn: cn=group1,ou=myunit,o=myorg,c=US
member: cn=user1, ou=otherunit, o=myorg, c=US
member: cn=user12, ou=otherunit, o=myorg, c=US
Se um objeto
do tipo listado em ldap.group.dnattributes for um membro do grupo sendo
procurado, ele será recursivamente procurado da mesma forma, até uma
profundidade de ldap.group.search.depth
- Primeiro o IBM HTTP Server usa o ldap.group.name.filter
e o ldap.user.cert.filter para converter o CN fornecido para o usuário
e o grupo em nomes distintos (DN). Em seguida, o IBM HTTP
Server procura usando o DN do grupo como uma base para entradas cujo valor
é o DN do usuário.
Exemplo:
ldapsearch ... -b "cn=grp1,ou=myunit,o=myorg,c=US"
"|((member=cn=user1,ou=otherunit,o=myorg,c=US)
(uniquemember=cn=user1,ou=otherunit,o=myorg,c=US))"
- Autorização baseada em atributos LDAP do usuário. Utilize o LDAP para
verificar as senhas do usuário e verificar se o usuário corresponde a um conjunto de atributos
(o atributo que identifica o usuário como sendo capaz de acessar
o recurso é uma parte da própria entrada LDAP dos usuários).
Exemplo:
LDAPRequire filter "(&(jobtitle=accountant)(location=newyork))"
Para
usar este formato de LDAPRequire, o IBM HTTP
Server deve usar o ldap.user.cert.filter para converter o CN fornecido
para o usuário em um DN. O IBM HTTP Server também deve procurar
usando o DN do usuário como uma base e usar o filtro de procura fornecido
na diretiva LDAPRequire. Se quaisquer resultados forem retornados, a autorização será bem-sucedida.
Exemplo:
ldapsearch ... -b "cn=user1,ou=otherunit,o=myorg,c=US" "(&(jobtitle=accountant)
(location=newyork))"
Alguns atributos (às vezes, chamado Funções
Dinâmicas) no LDAP são calculados dinamicamente pelo servidor LDAP e podem ter
semânticas diferentes que não são válidas em um filtro de procura. Tais valores falharão se usados no exemplo precedente e
não podem ser usados para autorização no IBM HTTP
Server.
- Apenas autenticação: Utilize o LDAP para verificar apenas as senhas do usuário.
Você pode
utilizar a diretiva Require para limitar os usuários específicos ou manter um arquivo de grupo
plano utilizando AuthGroupFile.
- Edite o arquivo de configuração ldap.prop. Se você
ainda não tiver um, poderá usar o arquivo ldap.prop.sample
fornecido com o IBM HTTP Server. Se tiver dúvidas sobre os valores corretos, verifique com o administrador do servidor LDAP. Atualize as seguintes diretivas com valores que
estão corretos para seu ambiente:
- Digite as informações de conexão do servidor da Web.
- Quando utilizar SSL, LDAPS ou LDAP sobre SSL:
Resultados
As procuras que utilizam as diretivas mod_ibm_ldap mantêm um conjunto de
conexões com o servidor que é autenticado como o usuário ldap.application.dn. A
primeira conexão é criada quando o primeiro pedido protegido do LDAP é recebido. As conexões serão mantidas abertas durante alguns segundos (ldap.idleConnection.timeout)
para procuras subsequentes nesta conexão ou conexões para outros pedidos.
Se
você estiver lendo os logs ou analisando um rastreio IP, a seguinte sequência de
eventos deverá ocorrer:
- O IBM HTTP Server inicia.
- Se LDAP_TRACE_FILE for configurado, ele terá algumas entradas para LDAP_obtain_config
- O primeiro pedido para o recurso protegido LDAP é recebido.
- O IBM HTTP Server se conecta ao LDAP usando o nome de usuário
ldap.application.dn e a senha em stash em ldap.application.password.stashFile
(Conexão de Aplicativo)
- O IBM HTTP Server executa uma procura sobre esta conexão
para converter o nome de usuário digitado pelo usuário ou o conteúdo de
seus certificados de cliente, em um Nome Distinto (DN) usando as configurações user.*.filter.
- O IBM HTTP Server se conecta ao servidor LDAP como nome do usuário/senha
fornecidos pelo cliente para verificar a autenticação (esta é uma "conexão do usuário"
com o servidor LDAP)
- Se quaisquer diretivas LDAPRequire estiverem em efeito para esta solicitação, o IBM HTTP
Server as processará da maneira descrita no procedimento precedente.
- O IBM HTTP Server desvincula a conexão do usuário
- A conexão do aplicativo é mantida para o próximo pedido