Que considerações devem ser feitas ao determinar o formato da NC (nome comum)

Question

Estamos procurando melhorar a padronização & qualidade de dados em nosso diretório ativo. Ao fazer isso, encontramos inconsistências no formato do distinguishedName ; especificamente o formato do CN em si. Geralmente, temos consistência razoável (embora nunca 100%) em uma entidade legal (UO de nível superior), mas em todas essas entidades, vários formatos são usados. Os mais comuns são:

• GivenName + ' ' + Surname , por ex. "John Bevan"
• Surname + ', ' + GivenName , por ex. "Bevan, John"
• string.ToUpper(SURNAME) + ' ' + GivenName , por ex. "BEVAN John"
• sAmAccountName , por ex. "ukjlb023"

Existem orientações sobre o que faz um bom formato ou considerações a serem tomadas 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, usando apenas givenName você teria que acrescentar um valor a muitas entradas para evitar colisões para todos, menos para os mais raros nomes).
• Valores imutáveis são melhores (por exemplo, como alguns sistemas usam o DN como um identificador, então alterar o CN que faz parte do DN pode ter efeitos colaterais no acesso a esses sistemas).
• Presumivelmente, há um benefício em usar nomes significativos, pois isso permite que uma pessoa calcule a conta à qual o 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 + ', ' + GivenName inclui uma vírgula, que é um caractere especial no DN , portanto, deve ser escapado. Ao evitar caracteres especiais no CN, limitamos o impacto de bugs em software / queries / scripts (também há uma desvantagem em relação a isso, pois esses bugs são mais propensos a passar despercebidos).
• Presumivelmente, há um índice aplicado a esse campo, portanto, o que estiver à esquerda terá um impacto maior no desempenho da pesquisa. Se as pessoas tiverem mais probabilidade de conhecer os colegas que receberam nomes do que o sobrenome ou o sAmAccountName, talvez haja um pequeno benefício no desempenho ao colocar o givenName primeiro.
• Algumas pessoas são conhecidas por outros nomes (por exemplo, Robert- > Bob, Madeeha-> Dee, Ashish- > Ash / algumas pessoas simplesmente preferem ser referenciadas pelo seu nome do meio ou um nome totalmente diferente). Onde o apelido não é uma subseqüência do nome real, pode haver algum benefício na capacidade de busca incluindo este nome no CN; por exemplo. John \"JB\" Bevan (caracteres de escape necessários no DN, mas não no CN).

As minhas suposições estão corretas, ou alguma delas está apenas pensando demais no assunto?

Existem outras considerações a serem levadas em conta?

NB: Há uma questão relacionada: link - embora isso esteja focado na parte "como evitar colisões" da discussão.

    

Answer 1

Na minha experiência, não há. Eu vi grandes organizações (mais de 100.000) que adotaram diferentes formatos ao longo do tempo e são uma bagunça. Eu acho que algumas organizações usam givenName surName porque esse é o padrão.

Algo para manter em mente para grandes organizações globais, eu vi lugares onde as mulheres podem não querer usar seu sobrenome ou metade dos homens são chamados de Muhammad, eu vi nomes de personagens únicos como 's' ou sobrenome é tão longo que eles abreviam para 'M', então a combinação dada / sobrenome pode não funcionar tão bem quanto nas culturas ocidentais.

Há também o tópico de aquisições. Dependendo de como uma aquisição é tratada, é possível acabar com vários diretórios e um diretório meta 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 'padrão' cn para funcionários subseqüentemente onboarded, então é um pouco um 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 seu nome de usuário, poderá não produzir o resultado pretendido desejado.

Algumas organizações não confiam em cn, mas usam um ID de funcionário que possui um formato padrão armazenado em um atributo diferente.

Eu não ficaria preocupado com personagens que precisam ser escapados. Um nome distinto pode ter quase qualquer caractere e pessoas que trabalham com diretórios LDAP é seu trabalho para saber quais caracteres precisam ser escapados.