[Freeipa-users] Re: VMware vCenter Single Sign-On

2020-02-04 Thread Christopher Young via FreeIPA-users 
I gotta say, the unwillingness of large organizations like RedHat to
even consider this functionality is pretty amazing to see since there
was a bug filed 12 years ago to add properly support for RFC 4530
entryUUID.  At some point, it should be a matter of pride for the
directory services to add functionality that clearly there is a demand
for.  I understand a lack of resources, but this looks more like a
lack of overall desire when you look at the completely lack of
attention this type of stuff gets in Bugzilla.

Having said that, it is pretty strange for vCenter to have LDAP
requirements and lack of instructions/testing with hardly any
third-party LDAP solutions.  That kinda defeats the purpose of
supporting an open standard.

In any case, at least there is a solid answer.  This would be one
worth just putting in the FAQ or on pages referencing vCenter that is
basically unsupported and will not be worked.

-- Chris

On Tue, Feb 4, 2020 at 3:49 PM White, Daniel E. (GSFC-770.0)[NICS] via
FreeIPA-users  wrote:
>
> Reference Links:
>
> 12/19/2006 https://bugzilla.redhat.com/show_bug.cgi?id=220222 Bug 220222 - 
> [RFE] support for RFC 4530 entryUUID attribute [NEEDINFO]
>
> Product:   Red Hat Enterprise Linux 8
>
> Reported:2006-12-19 19:40 UTC by Victoriano Giralt
>
> Modified:2020-01-17 05:47 UTC (History)
>
>
>
> 01/04/2012 https://pagure.io/389-ds-base/issue/137  #137 No support for RFC 
> 4530 entryUUID attribute
>
> Last Modified 10/18/2017
>
>
>
> 04/04/2019 https://christopherdamerau.com/freeipa-as-vcsa-identity-source/
>
> 01/30/2019 
> https://www.reddit.com/r/redhat/comments/al3no8/does_identity_management_freeipa_and_vsphere/
>
> 04/04/2016 
> https://www.howtovmlinux.com/articles/vmware/vcenter/integrate-freeipa-idm-with-vcsa-vcenter-server-for-user-authentications.html
>
> 06/20/2017 https://kb.vmware.com/s/article/2064977  VMware Knowledge Base: 
> OpenLDAP schemas supported in VMware vCenter Single Sign-On (2064977)
>
> 11/22/2018 https://www.freeipa.org/page/V4/Data_transformation
>
>
>
> I have spent the last two days trying to get vSphere 6.7 SSO to talk to Red 
> Hat Identity Manager (FreeIPA v4.6.5)
>
> Group permissions from LDAP do not work in vSphere.  Period.  It tells me, " 
> "Unable to login because you do not have permission on any vCenter server 
> systems connected to this client"
>
>
>
> I can associate an LDAP user to a vSphere role at the global level, but that 
> won’t scale very far.
>
>
>
> QUESTION: Does anyone know of an OpenLDAP setup that satisfies the VMware KB 
> description ?
>
> I do not believe that such a critter exists unless it is a home-grown, custom 
> cobbled together monstrosity that would be a nightmare to maintain.
>
> This was my point to VMware support.
>
> They support Active Directory.
>
> They should support FreeIPA because their "OpenLDAP" setup probably does not 
> exist.
>
>
>
> I am looking for any recent information anyone may have about getting this to 
> work.
>
> I am also looking for more detail to support my claim to VMware that they 
> need to support FreeIPA.
>
> __
>
>
>
> Daniel E. White
> daniel.e.wh...@nasa.gov
>
> NICS Linux Engineer
> NASA Goddard Space Flight Center
> 8800 Greenbelt Road
> Building 14, Room E175
> Greenbelt, MD 20771
>
> Office: (301) 286-6919
>
> Mobile: (240) 513-5290
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Command to export sub-ca certificate

2020-02-04 Thread Fraser Tweedale via FreeIPA-users 
On Tue, Feb 04, 2020 at 01:51:43PM -0500, Rob Crittenden via FreeIPA-users 
wrote:
> Jakob Ackermann via FreeIPA-users wrote:
> > The client is joined to the IPA domain and gets a certificate from the
> > sub-ca `puppet` with `ipa-getcert request -x puppet`. In order to have
> > the puppet agent to be able to talk to puppet server I need the puppet
> > sub-ca certificate.
> > 
> > How can I distribute the sub-ca certificate to the client? Running
> > `ipa-certupdate` did not work.
> 
> Create a file containing the pem for the sub CA:
> 
> $ ipa ca-show test --certificate-out=/tmp/test.pem
> 
> Add that to the list of managed CA certs
> 
> # ipa-cacert-manage install /tmp/test.pem
> 
> Now ipa-certupdate will pull it.
> 

Alternatively, instead of adding the sub-CA cert to the trust store
directly, if the puppet agent trusts the main IPA CA then you can
add the puppet sub-CA certificate (Rob showed how to export that) to
the certificate chain presented by the Puppet server.

Cheers,
Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: pki-tomcat doesn't start, it can't update certificate

2020-02-04 Thread Rob Crittenden via FreeIPA-users 
Serge Barkov via FreeIPA-users wrote:
> It seems that the reason of the problem is in
> "404...The requested resource is not available" when ipa tryies to renew the 
> certificate with request
> https://ipa0.domain.com:8443/ca/agent/ca/profileReview
> When I try it certificate is good but the result is 404...
> 
> Are there any ideas where to look?

The CA is a deployed WAR file in tomcat. A 404 suggests the CA hasn't
started at all. Check the logs.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] VMware vCenter Single Sign-On

2020-02-04 Thread White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users 
Reference Links:
12/19/2006 https://bugzilla.redhat.com/show_bug.cgi?id=220222 Bug 220222 - 
[RFE] support for RFC 4530 entryUUID attribute [NEEDINFO]
Product:   Red Hat Enterprise Linux 8
Reported:2006-12-19 19:40 UTC by Victoriano Giralt
Modified:2020-01-17 05:47 UTC (History)

01/04/2012 https://pagure.io/389-ds-base/issue/137  #137 No support for RFC 
4530 entryUUID attribute
Last Modified 10/18/2017

04/04/2019 https://christopherdamerau.com/freeipa-as-vcsa-identity-source/
01/30/2019 
https://www.reddit.com/r/redhat/comments/al3no8/does_identity_management_freeipa_and_vsphere/
04/04/2016 
https://www.howtovmlinux.com/articles/vmware/vcenter/integrate-freeipa-idm-with-vcsa-vcenter-server-for-user-authentications.html
06/20/2017 https://kb.vmware.com/s/article/2064977  VMware Knowledge Base: 
OpenLDAP schemas supported in VMware vCenter Single Sign-On (2064977)
11/22/2018 https://www.freeipa.org/page/V4/Data_transformation

I have spent the last two days trying to get vSphere 6.7 SSO to talk to Red Hat 
Identity Manager (FreeIPA v4.6.5)
Group permissions from LDAP do not work in vSphere.  Period.  It tells me, " 
"Unable to login because you do not have permission on any vCenter server 
systems connected to this client"

I can associate an LDAP user to a vSphere role at the global level, but that 
won’t scale very far.

QUESTION: Does anyone know of an OpenLDAP setup that satisfies the VMware KB 
description ?
I do not believe that such a critter exists unless it is a home-grown, custom 
cobbled together monstrosity that would be a nightmare to maintain.
This was my point to VMware support.
They support Active Directory.
They should support FreeIPA because their "OpenLDAP" setup probably does not 
exist.

I am looking for any recent information anyone may have about getting this to 
work.
I am also looking for more detail to support my claim to VMware that they need 
to support FreeIPA.
__

Daniel E. White
daniel.e.wh...@nasa.gov
NICS Linux Engineer
NASA Goddard Space Flight Center
8800 Greenbelt Road
Building 14, Room E175
Greenbelt, MD 20771
Office: (301) 286-6919
Mobile: (240) 513-5290
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Command to export sub-ca certificate

2020-02-04 Thread Rob Crittenden via FreeIPA-users 
Jakob Ackermann via FreeIPA-users wrote:
> The client is joined to the IPA domain and gets a certificate from the
> sub-ca `puppet` with `ipa-getcert request -x puppet`. In order to have
> the puppet agent to be able to talk to puppet server I need the puppet
> sub-ca certificate.
> 
> How can I distribute the sub-ca certificate to the client? Running
> `ipa-certupdate` did not work.

Create a file containing the pem for the sub CA:

$ ipa ca-show test --certificate-out=/tmp/test.pem

Add that to the list of managed CA certs

# ipa-cacert-manage install /tmp/test.pem

Now ipa-certupdate will pull it.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Does anyone use phpldapadmin on FreeIPA/RH-IdM ?

2020-02-04 Thread Rob Crittenden via FreeIPA-users 
White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users wrote:
> I am just curious to browse the LDAP information.
> 
> Contrarywise, does anyone have any suggestions for a free, lightweight
> way to browse LDAP information in FreeIPA/RH-IdM ?

A lot of people use Apache studio.

https://directory.apache.org/studio/

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Does anyone use phpldapadmin on FreeIPA/RH-IdM ?

2020-02-04 Thread White, Daniel E. (GSFC-770.0)[NICS] via FreeIPA-users 
I am just curious to browse the LDAP information.
Contrarywise, does anyone have any suggestions for a free, lightweight way to 
browse LDAP information in FreeIPA/RH-IdM ?
__

Daniel E. White
daniel.e.wh...@nasa.gov
NICS Linux Engineer
NASA Goddard Space Flight Center
8800 Greenbelt Road
Building 14, Room E175
Greenbelt, MD 20771
Office: (301) 286-6919
Mobile: (240) 513-5290
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start

2020-02-04 Thread Florence Blanc-Renaud via FreeIPA-users 

On 2/3/20 9:07 AM, Jochen Demmer via FreeIPA-users wrote:

Hi,

unfortunately currently there's is no other node, which is why I'm 
trying to update to Fedora 31. I used to replicate between two machines 
but on got lost.
I installed a new machine which is supposed to work as my new replica 
but this is being virtualized in bhyve / FreeNAS and this doesn't allow 
Fedora 30 to be installed so I'm stuck with Fedora 31.
In the docs it's said that versions between replicas need to be 
consistent so I'm trying to update the only running FreeIPA node 
(srv107) to Fedora 31 first.



Ok, so in this case we need to work on this single node...


Jochen

On Monday, February 03, 2020 08:36 CET, Florence Blanc-Renaud via 
FreeIPA-users  wrote:

On 2/2/20 11:30 PM, Jochen Demmer via FreeIPA-users wrote:
> Hi,
>
> this is the outputs:
> [root@srv107 ipa]# openssl x509 -noout -in /var/lib/ipa/ra-agent.pem
> -serial -subject -issuer -nameopt RFC2253
> serial=15
> subject=CN=IPA RA,O=UNIX.domain.NET
> issuer=CN=Certificate Authority,O=UNIX.domain.NET
>
> [root@srv107 ipa]# openssl x509 -noout -in ra-agent.pem -serial -subject
> -issuer -nameopt RFC2253
> serial=15
> subject=CN=IPA RA,O=UNIX.domain.NET
> issuer=CN=Certificate Authority,O=UNIX.domain.NET
> [root@srv107 ipa]# ldapsearch -LLL -o ldif-wrap=no -x -D "cn=directory
> manager" -W -b uid=ipara,ou=people,o=ipaca dn description 
usercertificate

> Enter LDAP Password:
> dn: uid=ipara,ou=people,o=ipaca
> description: 2;21;CN=Certificate Authority,O=UNIX.domain.NET;CN=IPA
> RA,O=UNIX.domain.NET
We can see that there is an inconsistency between the 
/var/lib/ipa/ra-agent.pem file and the LDAP content. You need to choose 
which one to pick as the source of truth and update the other one.


If the cert in /var/lib/ipa/ra-agent.pem is still valid, you can use 
this one. To check the validity:

$ openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem

Look for the lines:
Validity
Not Before: 
Not After : 

If the cert is valid, use this one as source of truth and update the 
ldap entry with ldapmodify (the description attribute and the 
usercertificate attribute).


If the cert is not valid, you need to find which one in the ldap entry 
corresponds to the serial 21. I did not manage to read the content of 
the usercertificate attribute, did you cut the ldapsearch output?

I tried with
$ openssl x509 -noout -text
-BEGIN CERTIFICATE-
MII...
-END CERTIFICATE-

but the 2 certs in the usercertificate attribute failed with "unable to 
load certificate".


flo


> usercertificate::
> 
MIIDccCCAlqgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDcyODE0MTIyMFoXDTE4MDcxODE0MTIyMFowKjEXMBUGA1UECgwOVU5JWC5HT1NJWC5ORVQxDzANBfNVBAMMBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24aQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBkzCBkDAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9zcnYxMDcuZ29zaXgubmV0OjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAg6wMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAi8CxlPVaFHi7XlT1sSY74WPy9BlZW/Dt9by94wDCs14pZeMalmwkY8iHkvQtTagoS7y/Nq0p7PTHbcr7y9CisiAP+DykYZHdIyBtjrQ37GIADjyXhbYJ+Y90O/J24M2q2t1X8xbSIhxqQ8eN4ICTDHqzBIn2YkAHxT1QkitNIZWlMSWdEImcpmQB5CIU1q8swaK6u1k5ksC4mNwUxkSzi1nr+ixuuIkSDjuC3f1kGOaJGV92fJRk+TbRvP6hxKMY9ITwy0upwcUvO/Sv8kdJ21pJ/VJmxfZDilHW6ZrZtME6zaMUmVCVmchxIV2jTvJ3PCAqly6fI41oOsEoPSYu1Q==

> usercertificate::
> 
MIIadDCCAlygAwIBAgIBFTANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE4MDYyMDE0MTI1MloXDTIwMDYwOTE0MTI1MlowKjEXMBUGA1UEChMOVU5JWC5HT1NJWC5ORVQxDzANBgNVBAMTBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24qQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBlTCBkjAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjBABggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9pcGEtY2EudW5peC5nb3NpeC5uZXQvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUAA4IBAQB+WTlsE5LmEvbfEk/fOlKfwkNv187o/6AtwBxrjvC0D0QobfnxSIgd7R905haHf9fyONYsQKn8mlbghtY3URfGnfYNXJ9ez1pOqoCAlpy5Z5tvDlQMGvVVjk/9pSibTI90noZeMrUE+Tetq45c8ZjFXxcrH4R07xUDRXZg8AXviQMyclUSZbWKsIL7a979Hp13q8sJ8MAod1OhqdP6EOk84AOyRcQuRhv5uEdeDSN4k+4mMSZGnMlKO+0gKnhUIq63/TlW8wp7NhCE+kYdOkF4M0lBYOPE66d/4VdX45soMdp4WphjZMrirarhFJvHpHloUwdoiIFglPvOkvbWndbM

[Freeipa-users] Command to export sub-ca certificate

2020-02-04 Thread Jakob Ackermann via FreeIPA-users 
 The client is joined to the IPA domain and gets a certificate from the
sub-ca `puppet` with `ipa-getcert request -x puppet`. In order to have the
puppet agent to be able to talk to puppet server I need the puppet sub-ca
certificate.

How can I distribute the sub-ca certificate to the client? Running
`ipa-certupdate` did not work.

Thanks
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Framework Use of GSS Proxy

2020-02-04 Thread Alexander Bokovoy via FreeIPA-users 

On ma, 03 helmi 2020, TC Johnson via FreeIPA-users wrote:

Hi,

I'm looking to understand a little better how the framework is using
GSS Proxy to authenticate the user who is accessing the tools. The
information here
(https://www.freeipa.org/page/Troubleshooting/PrivilegeSeparation) is
nice and I've been reading through the numerous libraries, python
files, and configs... but I can't find how they are telling the WSGI
app to use GSS to impersonate.

Any guidance is appreciated, reading suggestions, examples, what have you :)


They aren't telling anyone, they don't need to. It is configured in
gssproxy:

[service/ipa-api]
  mechs = krb5
  cred_store = keytab:/var/lib/ipa/gssproxy/http.keytab
  cred_store = client_keytab:/var/lib/ipa/gssproxy/http.keytab
  allow_constrained_delegation = true
  allow_client_ccache_sync = true
  cred_usage = initiate
  euid = ipaapi

Since IPA framework doesn't have access to the actual keys and uses
GSSAPI code, GSS-Proxy's GSSAPI interposer proxies the calls to
GSS-Proxy from any GSSAPI application. GSS-Proxy configuration describes
what to allow here. And in case of IPA API, since the process runs under
effective UID of 'ipaapi', it matches the definition above.

So the flow goes like this:

 - mod_auth_gssapi does initial authentication and stores GSSAPI
   credentials (service ticket provided by the client) in a cred store,
   then returns a cookie that contains encrypted creds

 - for non-Kerberos case, IPA framework does run own kinit as a user and
   then does internal redirect to mod_auth_gssapi-protected end point
   that will generate a cookie as part of a subrequest.

 - when cookie is provided by the client, mod_auth_gssapi automatically
   handles its transformation into a proper GSSAPI cred store that is
   handled transparently by GSS-Proxy thanks to the interposer proxy.

 - so when IPA framework does the check that there is a known Kerberos
   principal in the context, we already deal with the credentials
   managed for us by mod_auth_gssapi + GSS-Proxy. At this point, we
   simply load 'default' creds and use them. From 'use' point of view,
   IPA framework just tries to connect to LDAP with SASL GSS-SPNEGO and
   that causes MIT Kerberos library to request a service ticket to LDAP.
   We don't have original user's TGT here, only a service ticket to
   ourselves (HTTP/...) and this means GSS-Proxy would have failed to
   unless constrained delegation is allowed. And it is allowed in
   GSS-Proxy configuration. Also, on KDC side it is allowed for HTTP/...
   principal on IPA masters to use constraint delegation on behalf of a
   user to obtain a service ticket to ldap/... and cifs/... principals.

 - once IPA framework gets a service ticket to ldap/... (or cifs/...,
   for trust-specific operations), it simply uses it. The target side
   (LDAP or SMB server) recognize that the ticket was obtained via
   constraint delegation and see the impersonated identity instead of
   HTTP/... principal.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: shouldn't freeipa work by default?

2020-02-04 Thread Harald Dunkel via FreeIPA-users 

On 2020-01-31 10:02, François Cami wrote:


We'd rather fail early and print that warning which lets the admin fix
the issue.
You can see the rationale in the upstream ticket:
https://pagure.io/freeipa/issue/5887


As an admin I won't touch user settings, esp. not the locale variables.
All I can do is to provide the locales.

The point is to make freeipa work by default. It did (up to version 4.4,
AFAIU), and now it doesn't. Of course a user has to expect errors if
he or she actively uses UTF-8 without setting the locales accordingly,
but this is not the case here. And its surely not a problem that freeipa
is supposed to resolve.

The point is to show an error if something in freeipa goes wrong. Pro-
actively printing an error message and exit(1) on *ipa help* gives a
very bad first impression. Shouldn't be too difficult to add some code
like
test -z "$LC_CTYPE$LC_ALL" && export LC_CTYPE=C.UTF-8

to get rid of the problem completely.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org