Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-22 Thread Rob Crittenden

Walter Meyer wrote:

Thanks for all of the tips. I am wondering what the best way to modify
the ldap (so I can change the password scheme) is. I tried getting the
389-console utility setup to connect but was unsuccesful. Should I
just use the command line ldap tools?


We don't configure things so the console will work. You'll need to use 
the LDAP command-line tools.


Something like:

% ldapmodify -x -D cn=directory manager -W
dn: cn=config
changetype: modify
add: passwordStorageScheme
passwordStorageScheme: YOUR_SCHEME

I'm assuming that you don't already have a scheme specified, the default.

rob



On Mar 19, 2010, at 4:43 PM, Rob Crittenden rcrit...@redhat.com wrote:


Walter Meyer wrote:

I will see if Salted SHA1 is supported and maybe Google hasn't
documented it yet. If not, the sync is done with the Google Servers
over SSL. And if only the Directory Manager can read the
userPassword attribute, would storing the userPassword attribute in
SHA1 be that insecure? What scenario could the passwords be
compromised if I went with this setup? Unless the Directory Manager
account was compromised wouldn't this be secure if all of the data
was being transmitted over SSL?
Also all logins to Google Apps are encrypted with SSL.

Ok, the SSL usage makes me feel better. Using a weaker password
encryption scheme isn't ideal but if you are protecting transmission
of it you are probably ok. The risk is that if somehow the hash did
get exposed it is relatively easier to crack it than a salted hash.
Risk is something you'll need to weigh specific to your environment,
this may be acceptable. It doesn't make my alarm bells go off but
I'm a pretty laid back guy :-)

In fact, this would be very cool if it worked. You might want to
file an RFE with the nice folks at Google to see if they'll support
salted hashes if they don't now and potentially move to a more
secure environment later.

As Simo pointed out you'll want to modify the default password
encryption scheme before adding your users so you don't have to
force round after round of password changes on them.

If you decide to try it out let us know how it works.

cheers

rob


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


Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-21 Thread Walter Meyer
Thanks for all of the tips. I am wondering what the best way to modify
the ldap (so I can change the password scheme) is. I tried getting the
389-console utility setup to connect but was unsuccesful. Should I
just use the command line ldap tools?

On Mar 19, 2010, at 4:43 PM, Rob Crittenden rcrit...@redhat.com wrote:

 Walter Meyer wrote:
 I will see if Salted SHA1 is supported and maybe Google hasn't
 documented it yet. If not, the sync is done with the Google Servers
 over SSL. And if only the Directory Manager can read the
 userPassword attribute, would storing the userPassword attribute in
 SHA1 be that insecure? What scenario could the passwords be
 compromised if I went with this setup? Unless the Directory Manager
 account was compromised wouldn't this be secure if all of the data
 was being transmitted over SSL?
 Also all logins to Google Apps are encrypted with SSL.

 Ok, the SSL usage makes me feel better. Using a weaker password
 encryption scheme isn't ideal but if you are protecting transmission
 of it you are probably ok. The risk is that if somehow the hash did
 get exposed it is relatively easier to crack it than a salted hash.
 Risk is something you'll need to weigh specific to your environment,
 this may be acceptable. It doesn't make my alarm bells go off but
 I'm a pretty laid back guy :-)

 In fact, this would be very cool if it worked. You might want to
 file an RFE with the nice folks at Google to see if they'll support
 salted hashes if they don't now and potentially move to a more
 secure environment later.

 As Simo pointed out you'll want to modify the default password
 encryption scheme before adding your users so you don't have to
 force round after round of password changes on them.

 If you decide to try it out let us know how it works.

 cheers

 rob

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


Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Walter Meyer
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.

On Thu, Mar 18, 2010 at 6:10 PM, Rob Crittenden 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
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Dmitri Pal
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 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
 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


Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Walter Meyer
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.

Thanks,
Walter

On Fri, Mar 19, 2010 at 11:25 AM, Dmitri Pal 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 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
  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

Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Rob Crittenden

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 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
https://www.redhat.com/mailman/listinfo/freeipa-users





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


Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Dmitri Pal
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?
 

Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Simo Sorce
On Thu, 18 Mar 2010 19:47:35 -0400
Walter Meyer wgme...@gmail.com 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.

By default we use Salted SHA (SSHA) for the userPassword attribute.
You can change it by changing the passwordStorageScheme attribute (see
chapter 7 of the directory server guide), but you will probably have to
perform a password change for each user that needs synchronization if
you already have passwords set, because the hash can be changed only
when the clear text password is available.

I have to say though that MD5/SHA1 are considered weak today, esp MD5.

Also you should make sure you understand the implication of exposing
your internal passwords over the network.

By using the same hash for google apps it means you users will send
their IPA password to google for authentication (hopefully over HTTPS)
so if someone can phish or mitm them they will have the right password
for both google apps *and* your company resources.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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


Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Walter Meyer
I will see if Salted SHA1 is supported and maybe Google hasn't documented it
yet. If not, the sync is done with the Google Servers over SSL. And if only
the Directory Manager can read the userPassword attribute, would storing the
userPassword attribute in SHA1 be that insecure? What scenario could the
passwords be compromised if I went with this setup? Unless the Directory
Manager account was compromised wouldn't this be secure if all of the data
was being transmitted over SSL?

Also all logins to Google Apps are encrypted with SSL.

Thanks,
Walter

On Fri, Mar 19, 2010 at 2:06 PM, Simo Sorce sso...@redhat.com wrote:

 On Thu, 18 Mar 2010 19:47:35 -0400
 Walter Meyer wgme...@gmail.com 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.

 By default we use Salted SHA (SSHA) for the userPassword attribute.
 You can change it by changing the passwordStorageScheme attribute (see
 chapter 7 of the directory server guide), but you will probably have to
 perform a password change for each user that needs synchronization if
 you already have passwords set, because the hash can be changed only
 when the clear text password is available.

 I have to say though that MD5/SHA1 are considered weak today, esp MD5.

 Also you should make sure you understand the implication of exposing
 your internal passwords over the network.

 By using the same hash for google apps it means you users will send
 their IPA password to google for authentication (hopefully over HTTPS)
 so if someone can phish or mitm them they will have the right password
 for both google apps *and* your company resources.

 Simo.

 --
 Simo Sorce * Red Hat, Inc * New York

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

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

Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Rob Crittenden

Dmitri Pal wrote:

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.


passsync is for syncing passwords with Active Directory.


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.


If they could use DS as a local backend then could just authenticate 
directly against the IPA LDAP server.


rob

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


Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Rob Crittenden

Walter Meyer wrote:
I will see if Salted SHA1 is supported and maybe Google hasn't 
documented it yet. If not, the sync is done with the Google Servers over 
SSL. And if only the Directory Manager can read the userPassword 
attribute, would storing the userPassword attribute in SHA1 be that 
insecure? What scenario could the passwords be compromised if I went 
with this setup? Unless the Directory Manager account was compromised 
wouldn't this be secure if all of the data was being transmitted over SSL?


Also all logins to Google Apps are encrypted with SSL.


Ok, the SSL usage makes me feel better. Using a weaker password 
encryption scheme isn't ideal but if you are protecting transmission of 
it you are probably ok. The risk is that if somehow the hash did get 
exposed it is relatively easier to crack it than a salted hash. Risk is 
something you'll need to weigh specific to your environment, this may be 
acceptable. It doesn't make my alarm bells go off but I'm a pretty laid 
back guy :-)


In fact, this would be very cool if it worked. You might want to file an 
RFE with the nice folks at Google to see if they'll support salted 
hashes if they don't now and potentially move to a more secure 
environment later.


As Simo pointed out you'll want to modify the default password 
encryption scheme before adding your users so you don't have to force 
round after round of password changes on them.


If you decide to try it out let us know how it works.

cheers

rob

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


Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-19 Thread Walter Meyer
Google Apps uses its own user database, as of now there is no way to direct
it to a backend one, so the only option is to sync with the Google Apps
database.

On Fri, Mar 19, 2010 at 4:28 PM, Rob Crittenden rcrit...@redhat.com wrote:

 Dmitri Pal wrote:

 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.


 passsync is for syncing passwords with Active Directory.


  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.


 If they could use DS as a local backend then could just authenticate
 directly against the IPA LDAP server.

 rob

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

Re: [Freeipa-users] Password Attribute Syncing Support

2010-03-18 Thread Rob Crittenden

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
https://www.redhat.com/mailman/listinfo/freeipa-users