A consulta LDAP no linux no AD retorna grupos sem membros

3

Estou usando o LDAP + kerberos para autenticar no Active Directory no Windows 2003 R2. Meu krb5.conf e ldap.conf parecem estar corretos (de acordo com praticamente todas as amostras que encontrei na net). Eu consigo acessar o host com as chaves de senha e ssh. Quando executo o getent passwd, todas as minhas contas de usuário do ldap são listadas com todos os atributos importantes. Quando eu executo o grupo getent, todos os grupos do ldap e seus gids estão listados, mas não há membros do grupo. Se eu executar o ldapsearch e filtrar qualquer grupo, os membros serão todos listados com o atributo "member". Portanto, os dados estão disponíveis para a tomada, não estão sendo analisados adequadamente. Parece que estou usando um mapeamento incorreto no ldap.conf, mas não consigo vê-lo. Eu tentei várias variações e todas deram o mesmo resultado.

Aqui está o meu ldap.conf atual:

host <ad-host1-ip> <ad-host2-ip>
base dc=my,dc=full,dc=dn
uri ldap://<ad-host1> ldap://<ad-host2>
ldap_version 3
binddn <mybinddn>
bindpw <mybindpw>
scope sub
bind_policy hard 
nss_reconnect_tries 3
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_reconnect_maxconntries 3
nss_map_objectclass posixAccount User
nss_map_objectclass posixGroup Group
nss_map_attribute uid sAMAccountName
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute cn cn
nss_map_attribute gecos displayName
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute uniqueMember member
pam_filter objectcategory=User
pam_login_attribute sAMAccountName
pam_member_attribute member
pam_password ad

Aqui está o kicker: esta configuração funciona 100% bem em uma caixa linux diferente com uma distro diferente. Não funciona na distro que estou planejando mudar. Eu instalei a partir do código-fonte as versões de pam_ldap e nss_ldap na nova caixa para corresponder à caixa antiga, que corrigiu outro problema que eu estava tendo com essa configuração.

Outra informação relevante é que a caixa original do AD era o Windows 2003. O espelho morreu com uma morte horrível no hardware, por isso estou tentando adicionar mais dois servidores 2003-R2 à árvore de espelhos e finalmente largar a caixa antiga de 2003. As novas caixas R2 parecem ter ingressado na floresta DC corretamente.

O que preciso fazer para que os grupos trabalhem? Eu exaurei todos os recursos que encontrei e preciso de um ângulo diferente. Qualquer entrada é apreciada.

Atualização de status, 31/07/09

Eu consegui ajustar meu arquivo de configuração para obter informações completas do AD e o desempenho é bom e rápido. Eu substituí as cópias reversas de pam_ldap e nss_ldap pelas cópias atuais para a distro que estou usando, então voltamos para uma instalação padrão pronta para uso. Aqui está minha configuração atual:

host <ad-host1-ip> <ad-host2-ip>
base dc=my,dc=full,dc=dn
uri ldap://<ad-host1> ldap://<ad-host2>
ldap_version 3
binddn <mybinddn>
bindpw <mybindpw>
scope sub
bind_policy soft 
nss_reconnect_tries 3
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_reconnect_maxconntries 3
nss_connect_policy oneshot
referrals no
nss_map_objectclass posixAccount User
nss_map_objectclass posixGroup Group
nss_map_attribute uid sAMAccountName
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute cn cn
nss_map_attribute gecos displayName
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute uniqueMember member
pam_filter objectcategory=CN=Person,CN=Schema,CN=Configuration,DC=w2k,DC=cis,DC=ksu,DC=edu
pam_login_attribute sAMAccountName
pam_member_attribute member
pam_password ad
ssl off
tls_checkpeer no
sasl_secprops maxssf=0

O problema restante agora é quando você executa o comando groups , nem todos os grupos inscritos são listados. Alguns são (um ou dois), mas não todos. As associações de grupo ainda são respeitadas, como o acesso a arquivos e impressoras. getent group foo ainda mostra que o usuário é um membro do grupo foo. Portanto, parece ser um bug de apresentação e não interfere na operação normal.

Parece também que algumas pesquisas de grupo (não determinei exatamente quantas) não são resolvidas corretamente, mesmo que o grupo esteja listado. Por exemplo, quando você executa " getent group bar ", nada é retornado, mas se você executar " getent group|grep bar " ou " getent group|grep <bar_gid> ", verá que ele realmente está listado e o nome do grupo e gid estão corretos.

Isso ainda parece uma pesquisa LDAP ou um erro de mapeamento, mas não consigo descobrir o que é. Eu estou muito mais perto do que no início da semana, mas eu realmente gostaria de ter este último detalhe resolvido.

    
por SethG 30.07.2009 / 00:28

2 respostas

1

Pode ser o mesmo caso em que corri há pouco tempo. Se o seu grupo AD tem muitos membros, isso causou tal erro no Linux (em algum lugar no nível getent ou pouco antes - ldapsearch funcionou bem).

Mais precisamente, o erro não é sobre um número específico de membros, mas sim sobre o número de caracteres por "linha de grupo" (linha de pensamento de / etc / group) sendo maior que 1023 caracteres. Eu não olhei por que esse limite está lá e por que 1024. Eu acabei de criar um segundo grupo e movi membros excessivos lá.

    
por 11.06.2010 / 00:42
1

Esta é realmente uma coisa muito fácil de corrigir, você precisa adicionar o seguinte ao seu ldap.conf:

nss_schema rfc2307bis

Isto diz para enumerar grupos com um DN em vez de apenas o CN. Observe também que você pode usar os atributos nativos do RFC2307 agora (gecos, uid etc) contanto que você tenha um DC 2003R2 ou mais recente.

    
por 24.05.2012 / 19:30