Re: [Freeipa-users] Question on AD to freeipa sync

2011-10-05 Thread Ondrej Valousek

Submitted RFEs #743503,#743505,#743505 and #743509 into RedHat bugzilla (I have 
no login to fedorahosted.org so I could not submit to upstream).
Take them as a wish-list only and feel free to close them if they do not fit 
into the IPA roadmap.

Thanks!
Ondrej

On 10/04/2011 04:47 PM, Stephen Gallagher wrote:

These are all great ideas, Ondrej. Would you mind opening RFE bugs for
them? You can file them upstream at https://fedorahosted.org/sssd or in
Red Hat Bugzilla https://bugzilla.redhat.com in the sssd component.

On Tue, 2011-10-04 at 16:29 +0200, Ondrej Valousek wrote:

Can you provide more information here? We DO have support for automatic
detection based on DNS SRV records. Does a DC locator use some other
mechanism?


Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin.
I have machine in Prague and I want it to join CONTOSO.COM. Now if I
used:

dns_discovery_domain = contoso.com

sssd would try to connect to any DC in the domain - even the one in
Dublin, completely ignoring sites.
I have to use:

dns_discovery_domain = Prague._sites.contoso.com

To force it to use Prague DCs only.
My understanding is, that the DC locator tries to communicate with
DC's first to determine local site and remote DC's are only used if no
valid/working DC can be found in the local site (Prague in this case).


I'm not sure what you mean by this? Do you mean you don't want to have
to specify ldap_schema = rfc2307bis and have it instead auto-detected?

That's trickier than it sounds.


well this is a really small one. I would say it would be perfectly
sufficient to introduce something like:

ldap_schema=msrfc2307bis

which would be equivalent to:

ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_home_directory = unixHomeDirectory
ldap_schema = rfc2307bis

also, the ldap bind mechanism negotiation could be potentially
improved, now I have to explicitly specify

ldap_sasl_mech = GSSAPI

otherwise sssd tries to use SASL/EXTERNAL which fails when
communicating to AD controllers.


What features of the krb5 library do you mean? SSSD provides a locator
plugin that manages several features of the krb5 library, including
kinit and kpasswd.


The thing is that not all Linux apps are using sssd so we have to
remember to configure /etc/krb5.conf. too.
When using Centrify, all I need to do is:

# adjoin contoso.com

..which takes care of everything - /etc/nsswitch.conf, krb5.conf, PAM
modules, eeeverything. If I wanted to use sssd for the same job I have
to:

1. configure (manually) /etc/samba/smb.conf
2. net ads join (- just to get machine creds)
3. configure (manually) sssd.conf
4. configure (manually) PAM modules
5. configure (manually) krb5.conf

I understand that much of this is probably not sssd duty, but it would
be helpful to have some script around which would do the same job.


__
The information contained in this e-mail and in any attachments is
confidential and is designated solely for the attention of the
intended recipient(s). If you are not an intended recipient, you must
not use, disclose, copy, distribute or retain this e-mail or any part
thereof. If you have received this e-mail in error, please notify the
sender by return e-mail and delete all copies of this e-mail from your
computer system(s). Please direct any additional queries to:
communicati...@s3group.com. Thank You. Silicon and Software Systems
Limited (S3 Group). Registered in Ireland no. 378073. Registered
Office: South County Business Park, Leopardstown, Dublin 18

__

___
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



The information contained in this e-mail and in any attachments is confidential 
and is designated solely for the attention of the intended recipient(s). If you 
are not an intended recipient, you must not use, disclose, copy, distribute or 
retain this e-mail or any part thereof. If you have received this e-mail in 
error, please notify the sender by return e-mail and delete all copies of this 
e-mail from your computer system(s).
Please direct any additional queries to: communicati...@s3group.com.
Thank You.
Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 
378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Question on AD to freeipa sync

2011-10-05 Thread Dmitri Pal
On 10/05/2011 04:02 AM, Ondrej Valousek wrote:
 Submitted RFEs #743503,#743505,#743505 and #743509 into RedHat
 bugzilla (I have no login to fedorahosted.org so I could not submit to
 upstream).
 Take them as a wish-list only and feel free to close them if they do
 not fit into the IPA roadmap.

Thank you for taking time and doing this!


 Thanks!
 Ondrej

 On 10/04/2011 04:47 PM, Stephen Gallagher wrote:
 These are all great ideas, Ondrej. Would you mind opening RFE bugs for
 them? You can file them upstream at https://fedorahosted.org/sssd or in
 Red Hat Bugzilla https://bugzilla.redhat.com in the sssd component.

 On Tue, 2011-10-04 at 16:29 +0200, Ondrej Valousek wrote:
 Can you provide more information here? We DO have support for automatic
 detection based on DNS SRV records. Does a DC locator use some other
 mechanism?

 Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin.
 I have machine in Prague and I want it to join CONTOSO.COM. Now if I
 used:

 dns_discovery_domain = contoso.com

 sssd would try to connect to any DC in the domain - even the one in
 Dublin, completely ignoring sites.
 I have to use:

 dns_discovery_domain = Prague._sites.contoso.com

 To force it to use Prague DCs only.
 My understanding is, that the DC locator tries to communicate with
 DC's first to determine local site and remote DC's are only used if no
 valid/working DC can be found in the local site (Prague in this case).

 I'm not sure what you mean by this? Do you mean you don't want to have
 to specify ldap_schema = rfc2307bis and have it instead auto-detected?

 That's trickier than it sounds.

 well this is a really small one. I would say it would be perfectly
 sufficient to introduce something like:

 ldap_schema=msrfc2307bis 

 which would be equivalent to:

 ldap_user_object_class = user
 ldap_group_object_class = group
 ldap_user_home_directory = unixHomeDirectory
 ldap_schema = rfc2307bis

 also, the ldap bind mechanism negotiation could be potentially
 improved, now I have to explicitly specify

 ldap_sasl_mech = GSSAPI

 otherwise sssd tries to use SASL/EXTERNAL which fails when
 communicating to AD controllers.

 What features of the krb5 library do you mean? SSSD provides a locator
 plugin that manages several features of the krb5 library, including
 kinit and kpasswd.

 The thing is that not all Linux apps are using sssd so we have to
 remember to configure /etc/krb5.conf. too.
 When using Centrify, all I need to do is:

 # adjoin contoso.com

 ..which takes care of everything - /etc/nsswitch.conf, krb5.conf, PAM
 modules, eeeverything. If I wanted to use sssd for the same job I have
 to:

 1. configure (manually) /etc/samba/smb.conf
 2. net ads join (- just to get machine creds)
 3. configure (manually) sssd.conf
 4. configure (manually) PAM modules
 5. configure (manually) krb5.conf

 I understand that much of this is probably not sssd duty, but it would
 be helpful to have some script around which would do the same job.


 __
 The information contained in this e-mail and in any attachments is
 confidential and is designated solely for the attention of the
 intended recipient(s). If you are not an intended recipient, you must
 not use, disclose, copy, distribute or retain this e-mail or any part
 thereof. If you have received this e-mail in error, please notify the
 sender by return e-mail and delete all copies of this e-mail from your
 computer system(s). Please direct any additional queries to:
 communicati...@s3group.com. Thank You. Silicon and Software Systems
 Limited (S3 Group). Registered in Ireland no. 378073. Registered
 Office: South County Business Park, Leopardstown, Dublin 18 

 __

 ___
 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

 
 The information contained in this e-mail and in any attachments is
 confidential and is designated solely for the attention of the
 intended recipient(s). If you are not an intended recipient, you must
 not use, disclose, copy, distribute or retain this e-mail or any part
 thereof. If you have received this e-mail in error, please notify the
 sender by return e-mail and delete all copies of this e-mail from your
 computer system(s). Please direct any additional queries to:
 communicati...@s3group.com. Thank You. Silicon and Software Systems
 Limited (S3 Group). Registered in Ireland no. 378073. Registered
 Office: South County Business Park, Leopardstown, Dublin 18
 


 

Re: [Freeipa-users] freeRADIUS?

2011-10-05 Thread Dmitri Pal
On 10/04/2011 11:14 AM, John Dennis wrote:
 On 10/04/2011 10:50 AM, Jimmy wrote:
 I've been searching and see a few references to freeRADIUS used with
 FreeIPA, but I don't see any substantial information on the subject. Is
 there a procedure to use FreeIPA with freeRADIUS? I have a standalone
 openldap/freeradius server that I would like to eliminate if possible.

 Integrating FreeRADIUS with IPA is on the long term roadmap. It's not
 as easy as one might imagine. The fundamental problem is that many of
 the RADIUS authentication methods require access to the user's
 cleartext password or hashes we feel are insecure. This presents a
 design issue for us to resolve, as such it has been pushed out.

 Refer to this chart for more information:

 http://deployingradius.com/documents/protocols/compatibility.html


OK. This could have created a wrong impression the freeRADIUS can't be
used now with IPA. This is wrong. There is no tight integration but IPA
for sure can act as an authentication oracle for freeRADIUS.
http://deployingradius.com/documents/protocols/oracles.html

You have to use: EAP-TTLS as an outer tunnel, PAP as an inner tunnel and
configure freeRADIUS to do bind operation against IPA as if it is an
LDAP server (or you can use pam for that if you want, with SSSD you
might get offline caching if you connection between RADIUS host and IPA
might be disrupted, but if they are on the same box or connection is
reliable it might make sense to use direct ldap bind rather than use the
PAM stack) .
How to do all this can be found in the RADIUS manual. If you find some
interesting gotchas related to IPA or SSSD in this setup please share
with us. Also if you find this information not sufficient let us know
and we will try to help you find the right documentation.

-- 
Thank you,
Dmitri Pal

Sr. 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] freeRADIUS?

2011-10-05 Thread John Dennis

On 10/05/2011 09:44 AM, Dmitri Pal wrote:

On 10/04/2011 11:14 AM, John Dennis wrote:

On 10/04/2011 10:50 AM, Jimmy wrote:

I've been searching and see a few references to freeRADIUS used with
FreeIPA, but I don't see any substantial information on the subject. Is
there a procedure to use FreeIPA with freeRADIUS? I have a standalone
openldap/freeradius server that I would like to eliminate if possible.


Integrating FreeRADIUS with IPA is on the long term roadmap. It's not
as easy as one might imagine. The fundamental problem is that many of
the RADIUS authentication methods require access to the user's
cleartext password or hashes we feel are insecure. This presents a
design issue for us to resolve, as such it has been pushed out.

Refer to this chart for more information:

http://deployingradius.com/documents/protocols/compatibility.html



OK. This could have created a wrong impression the freeRADIUS can't be
used now with IPA. This is wrong. There is no tight integration but IPA
for sure can act as an authentication oracle for freeRADIUS.
http://deployingradius.com/documents/protocols/oracles.html

You have to use: EAP-TTLS as an outer tunnel, PAP as an inner tunnel and
configure freeRADIUS to do bind operation against IPA as if it is an
LDAP server (or you can use pam for that if you want, with SSSD you
might get offline caching if you connection between RADIUS host and IPA
might be disrupted, but if they are on the same box or connection is
reliable it might make sense to use direct ldap bind rather than use the
PAM stack) .
How to do all this can be found in the RADIUS manual. If you find some
interesting gotchas related to IPA or SSSD in this setup please share
with us. Also if you find this information not sufficient let us know
and we will try to help you find the right documentation.



Sure, but the typical stumbling block is that in the majority of cases 
the goal is transparent wireless authentication by supplicants in their 
default configuration. It's usually difficult to get users to properly 
configure their supplicants and for some versions of Windows it may not 
be possible at all without installing a different supplicant. Then there 
is is the issue of getting the radius CA cert into each client or 
telling users to disable cert validation which is not something we 
should be doing. In short, there are logistical problems which may not 
meet real world needs. It's hard to know a prori if the above will meets 
the needs or not, perhaps it will so it's good Dmitri posted the suggestion.


--
John Dennis jden...@redhat.com

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