[Freeipa-users] Re: keycloak - the other way around?
On ma, 27 kesä 2022, lejeczek via FreeIPA-users wrote: On 09/11/2021 06:40, Alexander Bokovoy wrote: On ti, 09 marras 2021, Fraser Tweedale wrote: On Mon, Nov 08, 2021 at 09:45:39PM +, lejeczek via FreeIPA-users wrote: Hi guys. I've only stumbled upon whole Keycloak thing thus go easy on me please. I wonder if Keycload can be a "provider" to freeIPA in some way? One such a scenario where I think Keycloak might be a golden egg - if it worked that is - is as a "middle-man" for user base between(or from to) AD and freeIPA when full & legit trust is not possible. Does that make sense? many thanks, L. Hi L, It does make sense, and IIRC it is being worked on. That is, authenticating to FreeIPA realm as "external identities" by way of SAML or OpenID Connect assertions. Adding Alexander, who may be able to comment further. There is an ongoing work to enable this feature. It is not ready yet for any testing as we had been distracted with more important work[1] recently. Hopefully, we'll get back to external IdP support[2] relatively soon. [1] https://lists.samba.org/archive/samba-technical/2021-November/136978.html [2] https://github.com/abbra/freeipa/blob/external-idp/doc/designs/external-idp/external-idp.md Hi guys. I wonder if you get any closer to perhaps to some test/trial in some foreseeable future? It is part of FreeIPA 4.9.10 release. Please see release notes for additional details. -- / 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: keycloak - the other way around?
On 09/11/2021 06:40, Alexander Bokovoy wrote: On ti, 09 marras 2021, Fraser Tweedale wrote: On Mon, Nov 08, 2021 at 09:45:39PM +, lejeczek via FreeIPA-users wrote: Hi guys. I've only stumbled upon whole Keycloak thing thus go easy on me please. I wonder if Keycload can be a "provider" to freeIPA in some way? One such a scenario where I think Keycloak might be a golden egg - if it worked that is - is as a "middle-man" for user base between(or from to) AD and freeIPA when full & legit trust is not possible. Does that make sense? many thanks, L. Hi L, It does make sense, and IIRC it is being worked on. That is, authenticating to FreeIPA realm as "external identities" by way of SAML or OpenID Connect assertions. Adding Alexander, who may be able to comment further. There is an ongoing work to enable this feature. It is not ready yet for any testing as we had been distracted with more important work[1] recently. Hopefully, we'll get back to external IdP support[2] relatively soon. [1] https://lists.samba.org/archive/samba-technical/2021-November/136978.html [2] https://github.com/abbra/freeipa/blob/external-idp/doc/designs/external-idp/external-idp.md Hi guys. I wonder if you get any closer to perhaps to some test/trial in some foreseeable future? thanks, L. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: freeipa/certmonger for openvpn user certificates
On 27/06/2022 15:16, Rob Crittenden wrote: lejeczek via FreeIPA-users wrote: On 03/06/2019 05:19, Alexander Bokovoy via FreeIPA-users wrote: On Mon, 03 Jun 2019, Patrick Spinler via FreeIPA-users wrote: Hi, I'm setting up an openvpn server and I'd like to use our already existing FreeIPA CA to issue user keys/certs for openvpn's use. Since our OpenVPN box is a freeipa client, I thought it'd be nice to use certmonger to issue and keep up to date these certs. Ergo, I've created a certificate profile: pat@apex-freeipa ~$ ipa certprofile-show --all OpenVPNUserCert dn: cn=OpenVPNUserCert,cn=certprofiles,cn=ca,dc=int,dc=apexmw,dc=com Profile ID: OpenVPNUserCert Profile description: OpenVPN User Certificates Store issued certificates: FALSE objectclass: ipacertprofile, top And also a CA acl. For experimentation (and working vs our test freeipa) I've left this as wide open as I can: [pat@apex-freeipa ~]$ ipa caacl-show --all OpenVPN_User_Certificate_ACL dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com ACL name: OpenVPN_User_Certificate_ACL Enabled: TRUE CA category: all Profile category: all User category: all Host category: all Service category: all ipauniqueid: 6dde33a6-7849-11e9-aa05-525400b52c7b objectclass: ipaassociation, ipacaacl Then, on my openvpn server, I ask for a cert for use for one of my users (myself, in this case): root@apex-openvpn:~# ipa-getcert request -f /etc/openvpn/client/pat.crt -k /etc/openvpn/client/pat.key -r -N 'CN=pat,O=INT.APEXMW.COM' -K pat -g 4096 --profile OpenVPNUserCert New signing request "20190603014016" added. But, it fails due to an access err vs the 'userCertificate' attribute of my account: root@apex-openvpn:~# ipa-getcert list (...snippy snip excess...) Request ID '20190603014016': status: CA_REJECTED ca-error: Server at https://apex-freeipa.int.apexmw.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com'.). stuck: yes key pair storage: type=FILE,location='/etc/openvpn/client/pat.key' certificate: type=FILE,location='/etc/openvpn/client/pat.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes If I look at the dirsrv log, here's the accesses I see for this request (trimmed off the date/time to make the lines a _little_ shorter): root@apex-freeipa slapd-INT-APEXMW-COM# grep conn=178 access | cut -d' ' -f3- conn=178 fd=114 slot=114 connection from 10.10.200.1 to 10.10.200.1 conn=178 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO conn=178 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0025554208 dn="fqdn=apex-openvpn.int.apexmw.com,cn=computers,cn=accounts,dc=int,dc=apexmw,dc=com" conn=178 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL conn=178 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0001319554 conn=178 op=2 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL conn=178 op=2 RESULT err=0 tag=101 nentries=1 etime=0.979573 conn=178 op=3 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL conn=178 op=3 RESULT err=0 tag=101 nentries=1 etime=0.736730 conn=178 op=4 SRCH base="cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaca)(cn=ipa))" attrs="" conn=178 op=4 RESULT err=0 tag=101 nentries=1 etime=0.499142 conn=178 op=5 SRCH base="cn=ipa,cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaCaId ipaCaSubjectDN cn ipaCaIssuerDN description" conn=178 op=5 RESULT err=0 tag=101 nentries=1 etime=0.482726 conn=178 op=6 SRCH base="cn=apex-freeipa.int.apexmw.com,cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=CA))" attrs=ALL conn=178 op=6 RESULT err=0 tag=101 nentries=1 etime=0.950646 notes=U conn=178 op=7 SRCH base="cn=accounts,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=p...@int.apexmw.com))" attrs=ALL conn=178 op=7 RESULT err=0 tag=101 nentries=1 etime=0.0002747849 conn=178 op=8 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin" conn=178 op=8 RESULT err=0 tag=120 nentries=0 etime=0.135034 conn=178 op=9 SRCH base="cn=request certificate ignore caacl,cn=virtual operations,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass" conn=178 op=9 RESULT err=0 tag=101 nentries=1 etime=0.932668 - entryLevelRights: none conn=178 op=10 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="distinguishedName" conn=178 op
[Freeipa-users] Re: freeipa/certmonger for openvpn user certificates
lejeczek via FreeIPA-users wrote: > > > On 03/06/2019 05:19, Alexander Bokovoy via FreeIPA-users wrote: >> On Mon, 03 Jun 2019, Patrick Spinler via FreeIPA-users wrote: >>> Hi, >>> >>> I'm setting up an openvpn server and I'd like to use our already >>> existing FreeIPA CA to issue user keys/certs for openvpn's use. Since >>> our OpenVPN box is a freeipa client, I thought it'd be nice to use >>> certmonger to issue and keep up to date these certs. >>> >>> Ergo, I've created a certificate profile: >>> >>> pat@apex-freeipa ~$ ipa certprofile-show --all OpenVPNUserCert >>> dn: cn=OpenVPNUserCert,cn=certprofiles,cn=ca,dc=int,dc=apexmw,dc=com >>> Profile ID: OpenVPNUserCert >>> Profile description: OpenVPN User Certificates >>> Store issued certificates: FALSE >>> objectclass: ipacertprofile, top >>> >>> And also a CA acl. For experimentation (and working vs our test >>> freeipa) I've left this as wide open as I can: >>> >>> [pat@apex-freeipa ~]$ ipa caacl-show --all OpenVPN_User_Certificate_ACL >>> dn: >>> ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com >>> >>> ACL name: OpenVPN_User_Certificate_ACL >>> Enabled: TRUE >>> CA category: all >>> Profile category: all >>> User category: all >>> Host category: all >>> Service category: all >>> ipauniqueid: 6dde33a6-7849-11e9-aa05-525400b52c7b >>> objectclass: ipaassociation, ipacaacl >>> >>> Then, on my openvpn server, I ask for a cert for use for one of my >>> users (myself, in this case): >>> >>> root@apex-openvpn:~# ipa-getcert request -f >>> /etc/openvpn/client/pat.crt -k /etc/openvpn/client/pat.key -r -N >>> 'CN=pat,O=INT.APEXMW.COM' -K pat -g 4096 --profile OpenVPNUserCert >>> New signing request "20190603014016" added. >>> >>> >>> But, it fails due to an access err vs the 'userCertificate' attribute >>> of my account: >>> >>> root@apex-openvpn:~# ipa-getcert list >>> (...snippy snip excess...) >>> Request ID '20190603014016': >>> status: CA_REJECTED >>> ca-error: Server at https://apex-freeipa.int.apexmw.com/ipa/xml >>> denied our request, giving up: 2100 (RPC failed at server. >>> Insufficient access: Insufficient 'write' privilege to the >>> 'userCertificate' attribute of entry >>> 'uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com'.). >>> stuck: yes >>> key pair storage: type=FILE,location='/etc/openvpn/client/pat.key' >>> certificate: type=FILE,location='/etc/openvpn/client/pat.crt' >>> CA: IPA >>> issuer: >>> subject: >>> expires: unknown >>> pre-save command: >>> post-save command: >>> track: yes >>> auto-renew: yes >>> >>> If I look at the dirsrv log, here's the accesses I see for this request >>> (trimmed off the date/time to make the lines a _little_ shorter): >>> >>> root@apex-freeipa slapd-INT-APEXMW-COM# grep conn=178 access | cut >>> -d' ' -f3- >>> conn=178 fd=114 slot=114 connection from 10.10.200.1 to 10.10.200.1 >>> conn=178 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO >>> conn=178 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0025554208 >>> dn="fqdn=apex-openvpn.int.apexmw.com,cn=computers,cn=accounts,dc=int,dc=apexmw,dc=com" >>> >>> conn=178 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=int,dc=apexmw,dc=com" >>> scope=0 filter="(objectClass=*)" attrs=ALL >>> conn=178 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0001319554 >>> conn=178 op=2 SRCH >>> base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 >>> filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL >>> conn=178 op=2 RESULT err=0 tag=101 nentries=1 etime=0.979573 >>> conn=178 op=3 SRCH >>> base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 >>> filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL >>> conn=178 op=3 RESULT err=0 tag=101 nentries=1 etime=0.736730 >>> conn=178 op=4 SRCH base="cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" >>> scope=2 filter="(&(objectClass=ipaca)(cn=ipa))" attrs="" >>> conn=178 op=4 RESULT err=0 tag=101 nentries=1 etime=0.499142 >>> conn=178 op=5 SRCH base="cn=ipa,cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" >>> scope=0 filter="(objectClass=*)" attrs="ipaCaId ipaCaSubjectDN cn >>> ipaCaIssuerDN description" >>> conn=178 op=5 RESULT err=0 tag=101 nentries=1 etime=0.482726 >>> conn=178 op=6 SRCH >>> base="cn=apex-freeipa.int.apexmw.com,cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" >>> scope=2 >>> filter="(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=CA))" >>> attrs=ALL >>> conn=178 op=6 RESULT err=0 tag=101 nentries=1 etime=0.950646 notes=U >>> conn=178 op=7 SRCH base="cn=accounts,dc=int,dc=apexmw,dc=com" scope=2 >>> filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=p...@int.apexmw.com))" >>> attrs=ALL >>> conn=178 op=7 RESULT err=0 tag=101 nentries=1 etime=0.0002747849 >>> conn=178 op=8 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin" >>> conn=178 op=8 RESULT err=0 tag=120 nentries=0 etime=0.135034 >>> conn=178 op=9 SRCH base="cn=request certificate ignore >>> ca
[Freeipa-users] Re: freeipa/certmonger for openvpn user certificates
On 03/06/2019 05:19, Alexander Bokovoy via FreeIPA-users wrote: On Mon, 03 Jun 2019, Patrick Spinler via FreeIPA-users wrote: Hi, I'm setting up an openvpn server and I'd like to use our already existing FreeIPA CA to issue user keys/certs for openvpn's use. Since our OpenVPN box is a freeipa client, I thought it'd be nice to use certmonger to issue and keep up to date these certs. Ergo, I've created a certificate profile: pat@apex-freeipa ~$ ipa certprofile-show --all OpenVPNUserCert dn: cn=OpenVPNUserCert,cn=certprofiles,cn=ca,dc=int,dc=apexmw,dc=com Profile ID: OpenVPNUserCert Profile description: OpenVPN User Certificates Store issued certificates: FALSE objectclass: ipacertprofile, top And also a CA acl. For experimentation (and working vs our test freeipa) I've left this as wide open as I can: [pat@apex-freeipa ~]$ ipa caacl-show --all OpenVPN_User_Certificate_ACL dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com ACL name: OpenVPN_User_Certificate_ACL Enabled: TRUE CA category: all Profile category: all User category: all Host category: all Service category: all ipauniqueid: 6dde33a6-7849-11e9-aa05-525400b52c7b objectclass: ipaassociation, ipacaacl Then, on my openvpn server, I ask for a cert for use for one of my users (myself, in this case): root@apex-openvpn:~# ipa-getcert request -f /etc/openvpn/client/pat.crt -k /etc/openvpn/client/pat.key -r -N 'CN=pat,O=INT.APEXMW.COM' -K pat -g 4096 --profile OpenVPNUserCert New signing request "20190603014016" added. But, it fails due to an access err vs the 'userCertificate' attribute of my account: root@apex-openvpn:~# ipa-getcert list (...snippy snip excess...) Request ID '20190603014016': status: CA_REJECTED ca-error: Server at https://apex-freeipa.int.apexmw.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com'.). stuck: yes key pair storage: type=FILE,location='/etc/openvpn/client/pat.key' certificate: type=FILE,location='/etc/openvpn/client/pat.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes If I look at the dirsrv log, here's the accesses I see for this request (trimmed off the date/time to make the lines a _little_ shorter): root@apex-freeipa slapd-INT-APEXMW-COM# grep conn=178 access | cut -d' ' -f3- conn=178 fd=114 slot=114 connection from 10.10.200.1 to 10.10.200.1 conn=178 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO conn=178 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0025554208 dn="fqdn=apex-openvpn.int.apexmw.com,cn=computers,cn=accounts,dc=int,dc=apexmw,dc=com" conn=178 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL conn=178 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0001319554 conn=178 op=2 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL conn=178 op=2 RESULT err=0 tag=101 nentries=1 etime=0.979573 conn=178 op=3 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL conn=178 op=3 RESULT err=0 tag=101 nentries=1 etime=0.736730 conn=178 op=4 SRCH base="cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaca)(cn=ipa))" attrs="" conn=178 op=4 RESULT err=0 tag=101 nentries=1 etime=0.499142 conn=178 op=5 SRCH base="cn=ipa,cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaCaId ipaCaSubjectDN cn ipaCaIssuerDN description" conn=178 op=5 RESULT err=0 tag=101 nentries=1 etime=0.482726 conn=178 op=6 SRCH base="cn=apex-freeipa.int.apexmw.com,cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=CA))" attrs=ALL conn=178 op=6 RESULT err=0 tag=101 nentries=1 etime=0.950646 notes=U conn=178 op=7 SRCH base="cn=accounts,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=p...@int.apexmw.com))" attrs=ALL conn=178 op=7 RESULT err=0 tag=101 nentries=1 etime=0.0002747849 conn=178 op=8 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin" conn=178 op=8 RESULT err=0 tag=120 nentries=0 etime=0.135034 conn=178 op=9 SRCH base="cn=request certificate ignore caacl,cn=virtual operations,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass" conn=178 op=9 RESULT err=0 tag=101 nentries=1 etime=0.932668 - entryLevelRights: none conn=178 op=10 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="distinguishedName" conn=178 op=10 RESULT err=0 tag=101 nentri
