Active Directory: el misterio de UnicodePwd de AD LDS
Servicios de directorio ligero de Active Directory utiliza procedimiento sofisticado para convertir y la autenticación de contraseñas.
Por Frank C. Rettig
Recientemente, uno de los clientes necesarios para mostrar determinada información a través de Internet de Active Directory. La intención era proporcionar autenticación (por motivos de inicio de sesión) para una aplicación externa sin exponer dichos atributos de la selección. Quizás se pregunte ¿qué es el punto de autenticación fuera de la aplicación. Coloca el onus en los usuarios de la aplicación, que el proveedor, lo que reduce la responsabilidad del propietario.
Exponer a Internet en un controlador de dominio suele ser una mala práctica, si se trata de que la exposición directamente desde el entorno de producción o a través de una red perimetral. La alternativa natural es colocar un servidor de Windows Server 2008 con la función de servicios de directorio ligero de Active Directory (AD LDS) que se ejecutan en la red perimetral.
AD LDS originalmente se conocía como Active Directory Application Mode (ADAM). En primer lugar era un complemento para Windows 2003, incluido con Windows 2003 R2 y ahora está disponible como función de servidor de Windows 2008 o Windows 7. En muchos aspectos, es casi igual a Active Directory. Como algunos dicen, es una versión de desplegable toned que carece de las funciones de la empresa completa. La implementación de AD LDS es prácticamente lo mismo en cualquier versión de Windows, aunque Windows Server 2008 R2 es la mejor opción ya que incluye la versión 2 de Windows PowerShell. Esta nueva versión de Windows PowerShell proporciona la capacidad de administración mejorada de los atributos de Active Directory o AD LDS que simplemente no están disponibles en las otras versiones de sistema operativo.
Vaya a la ligera
Si el foco está en Active Directory o AD LDS, ambos pueden tener el atributo unicodePwd. Este atributo se almacena en la partición de directorio y aplicaciones. Se supone que el servidor se ha promovido a un controlador de dominio de Active Directory o en la plantilla correcta de LDIF que tiene el atributo de un servidor se ha aplicado de AD LDS.
Con Active Directory o AD LDS, las aplicaciones utilizan ligero Directory Access Protocol (LDAP) versión 3.0 para consultar el directorio. Para ello, la aplicación (que se puede convertir Ldp.exe, Csvde.exe, LDIFDE.EXE, ADSIEdit.exe o algunas aplicaciones desarrolladas internamente) debe proporcionar la cuenta y la contraseña. Parece sencillo suficiente, ¿por qué, a continuación, es no? Proporcionar la contraseña es la parte fácil. Al obtener la contraseña almacenada en el atributo unicodePwd es el desafío. Aquí es la razón: Con aplicaciones o directorios más interactivo, normalmente nos estamos le pedirá que escriba la contraseña en su formato nativo. Si la contraseña no “ coche ”, es lo que se escriba. Como es el caso, al tener acceso a un dominio o bosque de Active Directory, o al obtener acceso a una instancia de AD LDS mediante ADSIedit o LDP para asignar o restablecer una contraseña para una cuenta determinada.
Cuando se necesita realizar cambios o incorporaciones de forma masiva a la vez, el programa LDIFDE.EXE es la mejor elección. Para agregar o actualizar el atributo unicodePwd, Microsoft requiere que el valor del atributo unicodePwd en formato unicode en base-64.
Lógica de Unicode base-64
¿Cómo se calcula el valor de unicode en base-64? Esto es donde comienza la diversión. Con suerte, se le disipar el misterio el unicodePwd (y otros atributos que siguen la misma codificación) todos a la vez.
En primer lugar, tenga en cuenta que las frases siguientes se anotan. Consulte los pasos 1 a 12 en de figura 1. Microsoft requiere la contraseña encerrarse entre comillas dobles y, a continuación, se debe convertir cada carácter (incluidas las comillas) a su equivalente de unicode. Esto significa debe primero encontrar los ASCII equivalentes para cada carácter y, a continuación, derive el valor hexadecimal de cada valor ASCII, cada valor hexadecimal con dos ceros de relleno (debido a que Windows se ajusta a UTF16) para que se representan 16 bits.
Una vez convertido, estos conjuntos hexadecimales especificados todos combina en una cadena larga. Debido a que se basa en base 64 de 6 bits, esta cadena se analiza cada seis caracteres de la izquierda. Si sigue siendo un sextet del hex incompleta, se completa a la derecha con ceros hasta que se representan los seis caracteres. A continuación, se convierte cada sextet hexadecimal en binario. Como ocurre con el binario, el análisis se realiza desde la derecha y cada seis caracteres.
Aunque no es necesario, para un sextet binario está incompleta, rellenar hacia la izquierda con ceros hasta que se representan los seis caracteres (Recuerde que el líder en ceros cero sigue igual, pero así resulta más fácil de leer debido a que los otros conjuntos también tengan seis caracteres). Ahora puede convertir cada valor binario analizado en su de 11 numérico equivalente. Usar ese número como índice para buscar a una tabla en base 64 (figura 2 ) y obtener el carácter. Cuando un sextet completa sólo se compone de ceros acolchados, están representados por el signo igual.
La figura 1 muestra, en los pasos 1 a 12, cómo el coche de palabra se convierte en **IgBjAGEAcgAiAA ==.**Margen derecho es necesario, al preparar el unicode en base64, que puede ver el texto resaltado en azul. Como en el margen izquierdo, representado por el texto resaltado en rojo, esto es sólo para que sea coherente y fácil de leer en comparación con los demás sextets binarios.
.jpg)
La figura 1Pasos para crear una contraseña en base64-unicode.
.png)
La figura 2Asignación de base 64.
Si se pregunta si esta lógica original es correcta, obtenga una copia del programa stringconverter.exe de gbordier.com/gbtools/stringconverter.htm de y ejecute la siguiente cadena de comando del símbolo del sistema de DOS:
stringconverter \"car\" /encode /unicode
IgBjAGEAcgAiAA==
Como puede ver los resultados son los mismos.
Crear contraseña de base 64-Unicode
Para la prueba inicial sencilla, mediante las siguientes funciones de Excel (figura 1 de se creó en Excel) le permitirán generar con rapidez el base64 Unicode correcto del texto escrito:
- CODE(): devuelve el valor numérico de un carácter
- DEC2HEX(): convierte un número decimal en hexadecimal
- Concatenate(): une varias cadenas en una cadena
- BIN2DEC(): convierte un número binario en decimal
- MID(): devuelve el carácter desde el centro de una cadena
La mejor manera de tratar con generar grandes cantidades de los valores de unicodePwd es escribir una secuencia de comandos. Si lo hace, el uso de VBA de Excel le permite ver todos los valores generados y mantenerlos dentro de la hoja de cálculo en el futuro. Utilice otra secuencia de comandos VBA, he podido generar un archivo LDIF para importar a la instancia AD LDS de forma instantánea.
Carga el valor de UnicodePwd Unicode base-64
Debido a que la unicodePwd se manipula mediante el programa LDIFDE.exe, cargando el unicodePwd debe ajustarse al formato de archivo LDIF. Puesto que la contratación de la función de Windows Server 2008 R2 AD LDS, este formato de archivo LDIF es lo que he seguido por lo que se ha cargado la información básica. Tenga en cuenta que la cuenta de usuario de John Pérez es el primero que tiene el valor de unicodePwd del coche de como IgBjAGEAcgAiAA ==.
dn: CN=JohnDoe,OU=Accounts,DC=CONTOSO,DC=COM
Changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: John Doe
givenName: John
sn: Doe
userPrincipalName: johnd@Contoso.COM
mail: johnd@Contoso.COM
unicodePwd::IgBjAGEAcgAiAA==\
msDS-UserAccountDisabled: FALSE
dn: CN=Jess Wanders,OU=Accounts,DC=CONTOSO,DC=COM
Changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Jess Wanders
givenName: Jess
sn: Wanders
userPrincipalName: JessW@Contoso.COM
mail: JessW@Contoso.COM
unicodePwd::IgA3ACQANQBNAHMAIwA0AEQAaQBHACIA
msDS-UserAccountDisabled: FALSE
Por lo tanto, para importar este archivo, suponiendo que su nombre de archivo es Accounts.ldf, escriba la siguiente sintaxis en la consola de línea de comandos de Windows Server 2008 R2:
C:\Windows\system32\LDIFDE –i –f Accounts.ldf.
Enlace y la contraseña de la cuenta de prueba
Después de cargar una o varias de las cuentas recién creadas para la partición de aplicación y conectarse o enlazar con el servicio LDAP con userPrincipalName de la cuenta y unicodePwd, lo ‘ importante para asegurarse de que el formato unicode en base-64 de la unicodePwd es correcto. La herramienta que funciona mejor y es fácil de usar es Ldp.exe. Es posible que piense que IgBjAGEAcgAiAA == es la contraseña correcta para ENTRAR cuando el uso de esta, pero no lo es. Es lo que originalmente comenzamos con: automóvil.
Una vez que se ha conectado a la instancia AD LDS utilizando LDP, enlazar con el nombre principal de la cuenta cargada y escriba la contraseña. Si siguió la lógica para crear el valor de unicode en base-64 unicodePwd correctamente, verá una confirmación positiva que aparece en la ventana LDP, que en realidad se enlazan a la instancia AD LDS con esa cuenta.
Uso de Windows PowerShell para actualizar el atributo UnicodePwd
Ahora, sería razonable si dije que LDIFDE.exe era la única herramienta alrededor capaz de realizar cambios masivos en el atributo unicodePwd. A continuación, no ha aprendido a generar el valor de unicode en base-64.
En Windows Server 2008 R2, Windows PowerShell v2 poner un poco mayor granularidad en su capacidad de manipular la selección de atributos en Active Directory y AD LDS. Trabajar con AD LDS, surgió con la sintaxis de figura 3 (note that for the sake of readability, I placed each command option on its own line) para lograr los mismos resultados que se hace de la secuencia de comandos VBA dentro de la hoja de cálculo de Excel.
Es obvio que con sólo unas pocas líneas de código de Windows PowerShell, puede realizar rápidamente los cambios necesarios sin tener que pasar a través de ARO al crear el valor unicode de base64 para todas las contraseñas. Se trata de una instrucción eficaces capacidades de Windows PowerShell, pero lo que respecta a costa de tiempo de procesamiento, teniendo en cuenta todo lo que ocurre en segundo plano. Esto es especialmente evidente si procesar cientos o miles de cuentas.
Por lo tanto, si en ocasiones, tiene que crear o actualizar algunas de las cuentas en vez, utilizar Windows PowerShell. Si siempre crea o actualiza cientos o miles de forma regular, el uso de LDIFDE.exe es mucho más rápido a largo plazo.
La figura 3Secuencia de comandos Windows PowerShell v2 para actualizar la contraseña de cuenta.
Import-Csv c:\scripts\accounts.csv |
New-ADUser
–Name $_.commonName
–GivenName $_.givenName
–Surname $_.sn
-EmailAddress $_.email
-Type user
-UserPrincipalName $_.userPrincipalName
–Server LDS01:389 |
Set-ADAccountPassword
-Identity $_.distinguishedName
-NewPassword (ConvertTo-SecureString -AsPlainText $_.Password -Force)
-Reset
-Server LDS01:389 |
Enable-ADAccount
-Identity $_.distinguishedName
-Server LDS01:389
Si trabaja con Active Directory o AD LDS (o incluso de ADAM en este caso), existen varias formas de actualizar el atributo unicodePwd. Si tiene una cuenta para modificarla, utilice Ldp.exe o ADSIedit para que se lleva a cabo. Si hay sólo unos cuantos vez, el uso de Windows PowerShell v2 en Windows Active Directory de Server 2008 R2/AD LDS funciona muy bien.
Sin embargo, si aún está trabajando con Windows Server 2003 o posterior y tiene cientos o miles de cuentas que necesitan actualizaciones constantes, realice el trabajo de preparación por adelantado para generar un valor base64 de unicode para el atributo unicodePwd. A continuación, utilizar LDIFDE.exe para cargar los cambios a la vez.
.jpg)
Frank Rettig es un consultor en Estados Unidos. Práctica del sector público, ubicado en el Washington, D.C., área, con 26 años de experiencia en trabajo nacionalmente y internacionalmente. Está especializado en la integración de directorios, la administración de identidades, las soluciones de movilidad y estándares de informática de gobierno. Se puede llegar a Frank en frank.rettig@microsoft.com.
Confirmaciones:
Me gustaría agradecer a los miembros del equipo ACE de seguridad de Microsoft Information Services (arquitecto de seguridad) de Roger Grimes y Shawn Rabourn (Asesor de seguridad) para validar este artículo y USPS Federal Services Anthony de Lagarde (Asesor) para la revisión de contenido.