[Freeipa-users] Password Attribute Syncing Support
Dmitri Pal
dpal at redhat.com
Fri Mar 19 18:03:01 UTC 2010
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 <dpal at redhat.com
> <mailto:dpal at redhat.com>> 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
> <rcritten at redhat.com <mailto:rcritten at redhat.com>
> > <mailto: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 <mailto:Freeipa-users at redhat.com>
> > 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
> Freeipa-users at redhat.com
> 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/
More information about the Freeipa-users
mailing list