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 <d...@redhat.com
> <mailto:d...@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
>     <rcrit...@redhat.com <mailto:rcrit...@redhat.com>
>     > <mailto:rcrit...@redhat.com <mailto:rcrit...@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@redhat.com <mailto:Freeipa-users@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@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/

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to