Os pontos-e-vírgulas WITH têm espaços permitidos como um delimitador para um valor de atributo do DirectoryString do Active Directory?

Question

Eu tenho um aplicativo da web de terceiros que está executando uma consulta LDAP para descobrir se o endereço de e-mail de um usuário existe no AD. A consulta é assim:

(&(objectClass=user)(proxyAddresses=SMTP:[email protected])) 

Meu valor do atributo proxyAddresses no AD é semelhante ao seguinte:

X500:/o=foo/ou=foo Group (ABC123)/cn=Foo3/cn=foouser (blah)123; SIP:[email protected]; smtp:[email protected]; smtp:[email protected]; SMTP:[email protected]

O aplicativo da web está recebendo resultados vazios de volta. Eu vejo um resultado semelhante quando eu verificar com o AD Explorer. Além disso, quando olho para a saída bruta no AD Explorer, ele coloca todo o valor do atributo em uma única linha, em vez de mostrar cada entrada SMTP e X500 em uma linha separada.

Tudo isso me faz pensar que o valor não pode ser delimitado corretamente.

Quando comparei o atributo com outro ambiente, o outro ambiente não tinha espaços entre os valores.

Por exemplo ... meu:

X500:/o=foo/ou=foo Group (ABC123)/cn=Foo3/cn=foouser (blah)123; SIP:[email protected]; smtp:[email protected]; smtp:[email protected]; SMTP:[email protected]

O outro ambiente:

X500:/o=foo/ou=foo Group (ABC123)/cn=Foo3/cn=foouser (blah)123;SIP:[email protected];smtp:[email protected];smtp:[email protected];SMTP:[email protected]

Então, minha pergunta é:

Os pontos-e-vírgulas WITH têm espaços permitidos como um delimitador para um valor de atributo do DirectoryString do Active Directory?

    

Answer 1

Do ponto de vista de uma consulta, o delimitador é, na verdade, apenas uma opção de exibição estética para apresentar os dados. Diferentes ferramentas exibirão os vários valores de diferentes maneiras. Verifique se você está usando a mesma versão da mesma ferramenta nos dois ambientes.

A guia attributes em DSA.MSC usa pontos e vírgulas com espaços, mas abre esse atributo para editar com o DSA e você obtém uma lista com cada atributo em uma nova linha. Alguns outros métodos que você pode consultar e exibir: CSVDE gerará um arquivo que usa ponto e vírgula. Get-Aduser usará "," na consulta geral, mas usará novas linhas quando você expandir o atributo.

csvde -r "(samaccountname=roadRunner)" -f this.csv -l proxyaddresses
get-aduser -ldapfilter "(samaccountname=roadRunner)" -prop proxyaddresses
(get-aduser -ldapfilter "(samaccountname=roadRunner)" -prop proxyaddresses).proxyaddresses

O usuário é encontrado quando você executa a mesma consulta com? get-aduser -ldapfilter "(&(objectClass=user)(proxyAddresses=SMTP:[email protected]))"

    

Answer 2

Acho que não existe um delimitador ou separador para atributos de valor múltiplo.

Se você importar ou exportar dados usando arquivos ldif, o formato ficará assim:

dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: This is the first description value
description: This is the second description value

E se eu consultar minha conta usando a ferramenta dsquery padrão, também recebo este formato

dsquery * "cn=my user name,ou=whatever,dc=sub,dc=domain,dc=tld" -scope base -attr * | findstr /i 
proxyAddresses: smtp:[email protected]
proxyAddresses: SMTP: [email protected]
...

Usar o ldapsearch de um host linux me fornece o mesmo formato ldif. Então, meu palpite é que o aplicativo não está analisando o resultado do filtro corretamente, ele deve estar em loop através da lista de valores retornada. Se isso não acontecer, então parece que há um bug no código deles.

De acordo com msdn o atributo Proxy-Addresses não tem um único valor e sua sintaxe é string unicode . Além disso, o msdn tem uma pequena entrada sobre as diferenças entre atributos únicos e de valor múltiplo msdn , mas não diz nada sobre delimitadores ou formatos (apenas que as entradas podem não estar vazias).