[Freeipa-users] Password Attribute Syncing Support

Rob Crittenden rcritten at redhat.com
Fri Mar 19 18:02:45 UTC 2010


Dmitri Pal wrote:
> Walter Meyer wrote:
>> Sorry I should have linked to the manual for it:
>> http://www.postini.com/webdocs/gads/admin
>>
>> 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
> server
> http://www.redhat.com/docs/manuals/dir-server/pdf/ds80admin.pdf
> you will find the section 16.1.x that talks about enabling different
> plugins.
> 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).

regards

rob

> 
> Thanks
> Dmitri
>> On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden <rcritten at redhat.com
>> <mailto:rcritten at redhat.com>> 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.
>>
>>     rob
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> 




More information about the Freeipa-users mailing list