Estamos procurando melhorar a padronização e a qualidade dos dados em nosso diretório ativo. Ao fazer isso, encontramos inconsistências no formato do distinguishedName; especificamente o formato do CNpróprio. Muitas vezes temos consistência razoável (embora nunca 100%) dentro de uma entidade legal (OU de nível superior), mas entre essas entidades, vários formatos são usados. Os mais comuns são:
GivenName + ' ' + Surnamepor exemplo, "John Bevan"Surname + ', ' + GivenNamepor exemplo, "Bevan, John"string.ToUpper(SURNAME) + ' ' + GivenNamepor exemplo, "BEVAN John"sAmAccountNamepor exemplo, "ukjlb023"
Existem diretrizes sobre o que é um bom formato ou considerações a serem feitas ao tomar essa decisão?
- Os valores devem ser únicos, então você quer algo que provavelmente não terá colisões com valores existentes (por exemplo, apenas usando
givenNamevocê teria que anexar um valor adicional a muitas entradas para evitar colisões para todos, exceto para os nomes mais raros). - Os valores imutáveis são melhores (por exemplo, como alguns sistemas usam o DN como identificador, portanto, alterar o CN que faz parte do DN pode afetar o acesso a esses sistemas).
- Presumivelmente, há um benefício em usar nomes significativos, pois isso permite que uma pessoa descubra a qual conta um CN/DN se refere sem ter que procurar outros atributos... mas isso não é crítico, pois essas informações podem ser facilmente consultadas.
- O formato
Surname + ', ' + GivenNameinclui uma vírgula, que é um caractere especial noDN, portanto, deve ser escapado. Ao evitar caracteres especiais no CN, estamos limitando o impacto de bugs em software/consultas/scripts (também há uma desvantagem nisso, pois é mais provável que esses bugs passem despercebidos). - Presumivelmente, há um índice aplicado a esse campo, portanto, o que estiver à esquerda terá maior impacto no desempenho da pesquisa. Dado que as pessoas são mais propensas a conhecer os nomes dos colegas do que o sobrenome ou sAmAccountName, talvez haja algum pequeno benefício de desempenho em colocar o
givenNameprimeiro. - Algumas pessoas são conhecidas por outros nomes (por exemplo, Robert->Bob, Madeeha->Dee, Ashish->Ash / algumas pessoas simplesmente preferem ser chamadas pelo nome do meio ou por um nome totalmente diferente). Quando o apelido não for uma subsequência do nome real, pode haver algum benefício na capacidade de pesquisa ao incluir esse nome no CN; por exemplo
John \"JB\" Bevan(caracteres de escape necessários em DN, mas não em CN).
Minhas suposições estão corretas ou alguma delas está apenas pensando demais no problema / longe?
Existem outras considerações a serem levadas em consideração?
NB: Há uma pergunta relacionada: https://stackoverflow.com/questions/7814569/what-do-people-use-for-cn-with-inetorgperson-in-ldap-directories - embora isso seja focado em "como evitar colisões" parte da discussão.
Na minha experiência não existem. Já vi grandes organizações (mais de 100.000) que adotaram formatos diferentes ao longo do tempo e são uma bagunça. Acho que algumas organizações usam givenName surName porque esse é o padrão.
Algo a ter em mente para grandes organizações globais, vi lugares onde as mulheres podem não querer usar seu sobrenome ou metade dos homens se chama Muhammad, já vi nomes de caracteres únicos como 's' ou o sobrenome é tão enquanto eles abreviam para 'M', então a combinação givenName/surName pode não funcionar tão bem quanto nas culturas ocidentais.
Há também o tema das aquisições. Dependendo de como uma aquisição é tratada, é possível acabar com vários diretórios e um metadiretório e vários formatos. A padronização do que é usado para cn pode não ser uma prioridade alta. Ou eles podem usar o formato cn 'padrão' para funcionários posteriormente integrados, então é um pouco mosh pit.
Cn=samAccountName pode parecer lógico, se samAccountName tiver um formato padronizado. Algumas organizações permitem que as pessoas escolham seu nome de usuário, portanto, se alguém selecionar 'jj89' como nome de usuário, pode não produzir o resultado pretendido.
Algumas organizações não dependem de cn, mas usam um ID de funcionário que tem um formato padrão armazenado em um atributo diferente.
Eu não estaria preocupado com caracteres que precisam ser escapados. Um nome distinto pode ter praticamente qualquer caractere, e as pessoas que trabalham com diretórios LDAP devem saber quais caracteres precisam ser escapados.