base de LDAP genérico para pesquisa?

Question

Estou a escrever algum código C ++ / Win32 de pesquisa para um usuário em um diretório LDAP (realmente eu preciso validar um nome de usuário / senha está correta e, em seguida, verificar a associação de grupo). Eu tenho o nome do usuário, por isso estou esperando algo como o seguinte irá funcionar:

(&(objectCategory=person)(objectClass=user)(uid={username}))

Quando eu chamo ldap_search com esta pesquisa / filtro, eu tenho que fornecer uma base inicial (node ??/ OU / whatever) para procurar. Mas eu não sei por onde começar a busca - tudo o que tenho é o nome de usuário. Existe uma maneira de especificar a raiz da árvore que irá trabalhar com o OpenLDAP, Active Directory, LDAP Netscape, etc, etc?

Além disso, qualquer pessoa que pode responder isso provavelmente poderia ajudar com isso: é o atributo uid universalmente suportado, ou que eu preciso para procurar um atributo diferente dependendo de que tipo de servidor LDAP eu estou falando? (Eu vi referências a pessoas que necessitam de procurar em uid, CN e até mesmo SAMAccountName).

Answer 1

Quanto à sua primeira pergunta sobre genericamente recuperar uma base de pesquisa:

Cada servidor de diretório LDAP (em conformidade com o protocolo LDAP eu acho) expõe algumas coisinhas operacionais sob um nó chamado RootDSE . Uma das coisas que você pode recuperar através de RootDSE é o namingContexts que essencialmente pode dizer o que as diferentes árvores são hospedados no servidor.

Assim, você pode recuperar uma base de pesquisa de nível superior para seu nome de usuário-search. Esteja ciente:. Algum LDAP (OpenLDAP por exemplo) servidores pode hospedar vários árvores então você tem que vir acima com uma solução quando vários contextos de nomeação são encontrados

O RootDSE pode ser recuperada por meio de consulta o servidor para o DN "" (string vazia) e specifiyng que pretende obter todos os atributos operacionais também. Apenas alguns exemplos para um servidor OpenLDAP:

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" +
# note the + returns operational attributes

Isso deve retornar algo similar ao mostrado abaixo (do OpenLDAP 2.4.8) - os valores entre parênteses são adicionados explicações e não são devolvidos pelo servidor:

dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=example,dc=com
namingContexts: dc=example,dc=net
monitorContext: cn=Monitor
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 (Contentsync RFC 4530)
[...]
supportedExtension: 1.3.6.1.4.1.4203.1.11.1 (ModifyPassword RFC3088)
[...]
supportedFeatures: 1.3.6.1.1.14 (Modify-Increment RFC4525)
[...]
supportedLDAPVersion: 3
supportedSASLMechanisms: NTLM
[...]
entryDN:
subschemaSubentry: cn=Subschema

( http://www.zytrax.com/books/ ldap / CH3 / # operacional )

---

Quanto à sua segunda pergunta sobre a disponibilidade do atributo uid:

Eu não acho que você deve confiar em um presente, uma vez que depende fortemente o esquema usado para armazenar os dados do usuário (embora a maioria dos user-esquema-classes terá um atributo uid eu acho). Mas isso depende da flexibilidade que você deseja colocar em seu programa. Talvez a melhor maneira seria fazer o configurável pelo usuário-filter-string pelo usuário final (você mesmo poderia fazer isso com a base de pesquisa que teria algumas vantagens de desempenho (não há necessidade de procurar a árvore inteira quando os usuários só estão localizados em um pequeno sub-árvore e não há necessidade de consultar o RootDSE)).

Answer 2

Eu não confiar em ser uid o atributo de pesquisa adequado para as entradas de usuário em LDAP. Muitas empresas só irá garantir a employeeID como sendo exclusivo dentro do DIT LDAP.

Answer 3

Você precisa definir o que recipiente para iniciar a busca. Então isso seria algo como

"LDAP://" + _ADSPath + ":" + _ADSPort + "/" + _ADSRootContainer

onde _ADSPath é o hostname do servidor / IP; _ADSPort é o número da porta (geralmente 389 por defeito); e _ADSRootContainer é o resto do caminho para o recipiente (como ou = usuários. O caminho vai depender da implementação você está procurando contra. Você pode iniciar-se maior do que o recipiente que contém os usuários e configurar os parâmetros no objeto de busca para usar uma pesquisa multi-nível. Mas vai ser muito mais lento.