Walter Meyer wrote: > We would be using Google Apps for our email system (and other services > included with GA like Google Docs etc.) I'd like to have one password > for users when they access their email via Google Apps, ideally the > users and passwords would be centralized in IPA. > > According to the Google documentation they only support updating user > passwords with the utility or through the API's that are encoded in > MD5, SHA1, or clear text. > > Another option I have considered is implementing a SSO solution like > Shibboleth (integrated with IPA) and having users login to their email > and other Google Apps services using that, as Google Apps supports > SAML. But the SAML SSO solution wouldn't work with IMAP and users > would have to maintain a separate password for this. Yet another > option would be to write a web app that would send a password change > simultaneously to Google Apps via their API's and to the IPA server, > so the passwords would be the same as long as the end-user only used > the web app to change their password. > > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html > > So my goal is to have one password for Directory Services (IPA) and > Google Apps services if possible. > I wonder if it would be better to take advantage of the passync utility provided by DS to replicate passwords and update them in the external source. Can Google Apps use a local DS instance as a back end? This way the IPA can be set up to update passwords in this instance via passync using of the shelf utilities provided by DS.
> Thanks, > Walter > > On Fri, Mar 19, 2010 at 11:25 AM, Dmitri Pal <[email protected] > <mailto:[email protected]>> 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. > > 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. > > 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. > > Thanks > Dmitri > > On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> 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 > > [email protected] <mailto:[email protected]> > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
