Re: [Freeipa-users] Password Attribute Syncing Support

[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: 

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  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

[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  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

[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  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

[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

[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

[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  wrote:

> On Thu, 18 Mar 2010 19:47:35 -0400
> 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.
>
> 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

[Simo Sorce]

On Thu, 18 Mar 2010 19:47:35 -0400
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.

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

[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  > 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
> 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
>
> Engin

Re: [Freeipa-users] Password Attribute Syncing Support

[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 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

[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  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  > > 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

[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  > 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

[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  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

[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

[Freeipa-users] Password Attribute Syncing Support

[Walter Meyer]

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.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users