[Modularit-users] Problemilla con el Samba de ModularIT

[Ancor González Sosa]

On Sábado, 19 de Diciembre de 2009 15:20:45 Ancor González Sosa escribió:
> On Sábado, 19 de Diciembre de 2009 10:50:58 usted escribió:
> > On Fri, Dec 18, 2009 at 12:29:52PM +0000, Ancor Gonzalez Sosa wrote:
> > > El Friday 18 December 2009 12:01:40 Miguel Armas escribió:
> > > > El día 18 de diciembre de 2009 11:49, Ancor Gonzalez Sosa
> > > >
> > > > <ancorgs at banot.net> escribió:
> > > > > Pues eso es lo que queríamos conseguir nosotros, pero sin éxito.
> > > > > ¿Pudiste hacerlo usando el campo userPassword con el formato normal
> > > > > de Unix? Nosotros no lo conseguimos. La única opción que vemos es
> > > > > usar otro atributo del LDAP (o cambiar ambas contraseñas en el
> > > > > momento que se cambie en el windows), porque no sabemos como pasar
> > > > > de algo al estilo "{SHA}blabla=" (que es la pinta que tiene el
> > > > > atributo userPassword en el LDAP)  al tipo de SHA o MD5 que
> > > > > entiende Google.
> > > >
> > > > No estoy muy seguro, pero creo recordar que el atributo userPassword
> > > > de OpenLDAP estaba en base64. Es decir, hacen el hash y luego lo
> > > > pasan a base64. Esto lo mire hace tiempo con knut cuando Foton estaba
> > > > haciendo una migracion. Igual el se acuerda mejor que yo...
> > >
> > > Sí, el atributo está en base64 y el de Google lo requiere en base16.
> > > Pero me temo que ese no es nuestro problema. Si yo paso el userpassword
> > > de base64 a base16 (pasando o no por ascii, que es lo mismo), el
> > > resultado es una ristra hexadecimal larguísima, mientras que Google
> > > Apps espera otra cosa.
> > >
> > > Si yo pongo la clave:
> > >   "hola"     (1)
> > > desde smbldap-tools eso se traduce (encriptado en MD5) a algo así como:
> > >    {MD5}RgPToAwCd2ov86MLJywMYg==     (2)
> > > que, en codificado base64, es:
> > > e01ENX1SZ1BUb0F3Q2Qyb3Y4Nk1MSnl3TVlnPT0=    (3)
> > > que es, ni más ni menos, el atributo userPassword de mi LDAP
> > > Si paso eso a hexadecimal (base16) obtengo un chorizo larguíiisimo.
> > >
> > > Sin embargo, Google, para la clave "hola" espera:
> > >   916f4c31aaa35d6b867dae9a7f54270d     (4)
> > > que es el MD5 de la clave "hola" pasado a hexadecimal (base16), es
> > > decir, es el resultado de la ejecución de la orden md5sum sobre la
> > > ristra "hola"
> >
> > No sé si es relevante, o sólo un ejemplo rápido, pero el MD5 de la
> > clave "hola" pasado a hexadecimal es:
> >
> > 4d186321c1a7f0f354b297e8914ab240
> >
> > El que tú has puesto sería para "hola"+<LF>.
> 
> Tienes razón, pero era sólo un ejemplo rápido.
> 
> > Tampoco consigo reproducir la clave (2). Para "hola" a mi me sale:
> >
> > TRhjIcGn8PNUspfokUqyQA==
> >
> > y para "hola\n":
> >
> > kW9MMaqjXWuGfa6af1QnDQ==
> >
> > que es el mismo MD5-digest pero en Base64. Con estos valores, pasar de
> > (2) a (4) consiste en base64-descodificar (2) (quitándole el prefijo
> > {MD5}) para obtener el digest en binario, y codificarlo en base16 (hexa)
> > para obtener la cadena que quiere Google.
> 
> Bueno. Si existe una solución (que creo que no, porque yo tampoco soy capaz
>  de llegar a (2) partiendo sólo de "hola"), lo cierto es que me has
>  aproximado a ella, porque yo estaba considerendo (2) como ASCII, no como
>  base64, por lo que la cuenta de dígitos no me salía ni de coña. Ahora sí
>  que me cuadra como pasar de (2) a 32 dígitos hexadecimales. Lo único que
>  tengo que desvelar ahora es porqué (2) no es igual que los MD5-digest que
>  obtuviste tú para "hola" y "hola\n", pero vuelvo a tener esperanzas de
>  conseguirlo.

Si para obtener (2) se hace lo que comentan en la Wikipedia [1], está jodida 
la cosa:

MD5-based scheme

[...]

First the passphrase and salt are hashed together, yielding an MD5 message 
digest. Then a new digest is constructed, hashing together the passphrase, the 
salt, and the first digest, all in a rather complex form. Then this digest is 
passed through a thousand iterations of a function which rehashes it together 
with the passphrase and salt in a manner that varies between rounds. The 
output of the last of these rounds is the resulting passphrase hash.

y el de SHA es aún peor (haciendo cosas como concatenar en cada iteración la 
primera letra de la clave).

Así que espero que (2) no se obtenga así. Seguiremos informando.

[1]  http://en.wikipedia.org/wiki/Crypt_%28Unix%29

> > > Pasar de (2) a (3) y viceversa es trivial (un simple cambio de base),
> > > pero no sé si es posible pasar de (2) -ó (3)- a (4). Eso es lo que
> > > necesito hacer, pero no lo he conseguido. Tal vez sean aplicaciones
> > > distintas del algoritmo MD5, no sé....  Tampoco sé si ha quedado claro
> > > el problema, pero al que me lo resuelva le regalo una cesta de navidad.
> >
> > Si te ha servido avisa, y te mando mi dirección o paso a buscarla por GC.
> >  ;-)
> 
> A ver si puedo hacer pruebas más serias y el lunes o el martes sabremos si
>  hay ganador :-)
> 
> > > Las soluciones alternativas incluyen, como mencionaba en el otro
> > > correo, usar otro atributo del LDAP para guardar la contraseña en
> > > "formato MD5 de google" (MD5sum) o bien cambiar la contraseña de google
> > > en el momento que se cambie en el windows/unix. Pero nos podría muy
> > > cachondos poder usar el atributo userPassword tal cuál.
> > >
> > > > Salu2!
> > >
> > > Saludos
> 
> Saludos
>