Dmitri Pal wrote:
Walter Meyer wrote:
Sorry I should have linked to the manual for it:

The Google Apps utility actually syncs passwords from LDAP to Google
Apps, not the other way around. The manual says that the utility
supports password attributes in MD5, SHA1, or Clear Text. So I am
wondering how they are stored in the IPA DS.

All three of these methods are completely insecure.
Rob correct me if I am wrong but if you log as a Directory Manager and
do a ldap search you will see all the passwords in a user entry.
AFAIR they are prefixed with the {type} something like this. But I do
not remember them being MD5, SHA1 or cleartext by default.

I believe the default is SSHA (salted SHA1).

If you look at the Administration manual for the underlaying directory
you will find the section 16.1.x that talks about enabling different
If you really want your IPA server to be insecure you can enable one of
those plugins and it will cause the creation of the passwords in a
corresponding scheme.
But this is all really insecure and should not be considered a viable
solution in a production environment.

Well, it certainly would be insecure for anyone that can read password values. By default nobody but the Directory Manager can get at the hash values.

What are the Google Applications that you need the password for?
Can you present the original use case and explain your goals?
May be there are more secure ways to make Google Apps happy then
creating insecure hashes in the IPA.

Google Apps covers a broad spectrum of things from gmail, calendar to docs, groups (mailing lists) and more.

I have to agree with Dmitri that I'd think long and hard about what implications there are changing the password storage schema and syncing them with another product. The Google sync documentation isn't exactly clear how the channel between the LDAP sync tool and the Google App server is protected. For example, the default configuration from the tool to the LDAP server is in the clear.

So I think that yes it is possible, I don't think I'd recommend it at this point.

You might check with the folks at Google. It could be that their documentation is behind the product so salted-SHA may already be supported. Then see if there is a way to secure all communication with SSL (it may very well work today, I didn't dive too deeply into the documentation).



On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden <
<>> wrote:

    Walter Meyer wrote:

        I am testing out FreeIPA and am wondering if FreeIPA is
        compatible with the Google Apps password sync utility.
        Specifically my question in relation to FreeIPA is how the
        password attribute is stored in the DS? Is it in any of these
        Google Apps supported formats: MD5, SHA1, or Plain Text? If
        not can I change it to one of these, or is this a bad idea?
        Thanks in advance.

    I'm not familiar with the Google Apps password sync utility, do
    you have any pointers describing how it works?

    In general though IPA needs to receive password changes in
    cleartext so it can generate matching kerberos keys. We can
    currently accept password changes over LDAP and the kerberos
    password protocol. Setting a password using either of these
    methods keeps all passwords/keys in sync. This requires an
    encrypted channel using either SSL or SASL.



Freeipa-users mailing list

Freeipa-users mailing list

Reply via email to