TDH Innovation CDH Mailbox via FreeIPA-users wrote:
> Dear Stephan,
>
>
> thanks for your reply.
>
>
> We are facing a similar issue (on cloudera CDH) and I wanted to ask you
>
> how you
>> removed the expired X3 CA and cross-signed X1 with
> `ipa-cacert-manage` (using the force flag),
>
> I do not see force flag in my v. (4.6.4) of the command...
The delete option was added in IPA 4.9.0.
You'd need to remove any certificates using an ldap editor or
ldapmodify/ldapdelete. The DN is going to look something like:
cn=SOME SUBJECT NAME,cn=certificates,cn=ipa,cn=etc,dc=example,dc=test
Just be careful, this is dealing with some IPA internals and you could
easily shoot yourself in the foot. I'd recommend saving off a copy of
the entry before trying to remove it so you can restore it if something
goes wrong.
Or snapshot your install. Or both.
rob
No because all the clients already trust and know the IPA CA.
Glad you got it working.
rob
Dungan, Scott A. wrote:
> Thanks, Rob.
>
> That worked. Does changing the web certs on the ipa servers require a ' ipa-certupdate' on all clients afterward? As far as I can tell, everything appears to be working normally without it.
>
> -Scott
>
> -----Original Message-----
> From: Rob Crittenden <rcritten(a)redhat.com>
> Sent: Monday, November 29, 2021 10:59 AM
> To: Dungan, Scott A. <sdungan(a)caltech.edu>; FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Subject: Re: [Freeipa-users] Revert web cert from 3rd party to internal ca
>
> Dungan, Scott A. wrote:
>> Rob,
>>
>> I don't think my response was sent correctly, so sending it again-apologies for any duplicates. Also, for misspelling your name.
>>
>>
>>
>> Bob,
>>
>> I ran the command on the first IPA server (idm1) as:
>>
>> ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k
>> /var/lib/ipa/private/httpd.key -p
>> /var/lib/ipa/passwds/$HOSTNAME-443-RSA -D idm1.xxx.xxx.edu -D
>> idm1.xxx.xxx.edu -C /usr/libexec/ipa/certmonger/restart_httpd -K
>> HTTP/idm1.xxx.xxx.edu -v -w
>>
>> It appears the command did not change the HTTP certificate on the IdM server. The time stamps and content of /var/lib/ipa/certs/httpd.crt and /var/lib/ipa/private/httpd.key are unchanged. Rather, the commercial cert is now tracked by certmonger?:
>>
>> ~]# getcert list
>>
>> ....
>> Request ID '20211119173141':
>> status: MONITORING
>> stuck: no
>> key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key',pinfile='/var/lib/ipa/passwds/xxx.xxx.xxx.edu-443-RSA'
>> certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt'
>> CA: IPA
>> issuer: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US
>> subject: CN=idm1.xxx.xxx.edu,OU=GPS,O=xxx,STREET=xxx,L=xxx,ST=xxx,postalCode=xxx,C=xxx
>> expires: 2022-01-02 15:59:59 PST
>> dns: idm1.xxx.xxx.edu
>> key usage: digitalSignature,keyEncipherment
>> eku: id-kp-serverAuth,id-kp-clientAuth
>> pre-save command:
>> post-save command: /usr/libexec/ipa/certmonger/restart_httpd
>> track: yes
>> auto-renew: yes
>>
>> I was expecting that the HTTP service on idm1 would get a new cert from the IPA self-signed CA, and then that would be tracked/renewed by certmonger. Certmonger will be unable to auto-renew the commercial cert, so tracking that is not useful.
>
> certmonger was too clever by half. It saw that the current cert is valid so went ahead and tracked it instead of requesting a replacement.
>
> You can stop the tracking with getcert stop-tracking -i 20211119173141
>
> Then backup /var/lib/ipa/private/httpd.key and /var/lib/ipa/certs/httpd.crt, just in case.
>
> If you then remove /var/lib/ipa/certs/httpd.crt and re-run the request command it will generate a new CSR using the existing key and an IPA should issue a replacement cert. You'll need to restart Apache afterward.
>
> rob
>
>>
>> -Scott
>>
>> -----Original Message-----
>> From: Rob Crittenden <rcritten(a)redhat.com>
>> Sent: Monday, November 15, 2021 11:04 AM
>> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
>> Cc: Dungan, Scott A. <sdungan(a)caltech.edu>
>> Subject: Re: [Freeipa-users] Revert web cert from 3rd party to
>> internal ca
>>
>> Dungan, Scott A. via FreeIPA-users wrote:
>>> Hi All
>>>
>>>
>>>
>>> After deploying FreeIPA with an embedded self-signed CA, the ipa
>>> servers were configured to use commercially signed, 3^rd party
>>> certificates for the HTTP service only. The directory server was left
>>> default. This was accomplished by importing the external CA and then
>>> the signed certificate, following the instructions on freeipa.org:
>>>
>>>
>>>
>>> ipa-cacert-manage -t C,, install InCommon_interm.cer
>>>
>>> ipa-certupdate
>>>
>>> ipa-server-certinstall --http /var/lib/ipa/private/httpd.key
>>> /var/lib/ipa/private/InCommon_signed.cer
>>>
>>> ipactl restart
>>>
>>>
>>>
>>> A commercially signed web certificate on the ipa servers is no longer
>>> required and we would like to revert back to using certificates from
>>> the freeipa self-signed CA. Is there a way to do so?
>>
>> This will request a new certificate using certmonger which will replace the 3rd party certificate and configure the renewal tracking. You may want to make a copy of the 3rd party cert and key just in case.
>>
>> ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k
>> /var/lib/ipa/private/httpd.key -p
>> /var/lib/ipa/passwds/ipa.example.test-443-RSA -D `hostname` -D
>> ipa-ca.example.test -C /usr/libexec/ipa/certmonger/restart_httpd -K
>> HTTP/`hostname` -v -w
>>
>> If you aren't using ACME you can skip the SAN for ipa-ca.example.test
>>
>> Restart the httpd service once it is issued.
>>
>> Adjust to your hostname/domain as needed.
>>
>> rob
>>
>
Dungan, Scott A. wrote:
> Rob,
>
> I don't think my response was sent correctly, so sending it again-apologies for any duplicates. Also, for misspelling your name.
>
>
>
> Bob,
>
> I ran the command on the first IPA server (idm1) as:
>
> ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/$HOSTNAME-443-RSA -D idm1.xxx.xxx.edu -D idm1.xxx.xxx.edu -C /usr/libexec/ipa/certmonger/restart_httpd -K HTTP/idm1.xxx.xxx.edu -v -w
>
> It appears the command did not change the HTTP certificate on the IdM server. The time stamps and content of /var/lib/ipa/certs/httpd.crt and /var/lib/ipa/private/httpd.key are unchanged. Rather, the commercial cert is now tracked by certmonger?:
>
> ~]# getcert list
>
> ....
> Request ID '20211119173141':
> status: MONITORING
> stuck: no
> key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key',pinfile='/var/lib/ipa/passwds/xxx.xxx.xxx.edu-443-RSA'
> certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt'
> CA: IPA
> issuer: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US
> subject: CN=idm1.xxx.xxx.edu,OU=GPS,O=xxx,STREET=xxx,L=xxx,ST=xxx,postalCode=xxx,C=xxx
> expires: 2022-01-02 15:59:59 PST
> dns: idm1.xxx.xxx.edu
> key usage: digitalSignature,keyEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/libexec/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
>
> I was expecting that the HTTP service on idm1 would get a new cert from the IPA self-signed CA, and then that would be tracked/renewed by certmonger. Certmonger will be unable to auto-renew the commercial cert, so tracking that is not useful.
certmonger was too clever by half. It saw that the current cert is valid
so went ahead and tracked it instead of requesting a replacement.
You can stop the tracking with getcert stop-tracking -i 20211119173141
Then backup /var/lib/ipa/private/httpd.key and
/var/lib/ipa/certs/httpd.crt, just in case.
If you then remove /var/lib/ipa/certs/httpd.crt and re-run the request
command it will generate a new CSR using the existing key and an IPA
should issue a replacement cert. You'll need to restart Apache afterward.
rob
>
> -Scott
>
> -----Original Message-----
> From: Rob Crittenden <rcritten(a)redhat.com>
> Sent: Monday, November 15, 2021 11:04 AM
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Cc: Dungan, Scott A. <sdungan(a)caltech.edu>
> Subject: Re: [Freeipa-users] Revert web cert from 3rd party to internal ca
>
> Dungan, Scott A. via FreeIPA-users wrote:
>> Hi All
>>
>>
>>
>> After deploying FreeIPA with an embedded self-signed CA, the ipa
>> servers were configured to use commercially signed, 3^rd party
>> certificates for the HTTP service only. The directory server was left
>> default. This was accomplished by importing the external CA and then
>> the signed certificate, following the instructions on freeipa.org:
>>
>>
>>
>> ipa-cacert-manage -t C,, install InCommon_interm.cer
>>
>> ipa-certupdate
>>
>> ipa-server-certinstall --http /var/lib/ipa/private/httpd.key
>> /var/lib/ipa/private/InCommon_signed.cer
>>
>> ipactl restart
>>
>>
>>
>> A commercially signed web certificate on the ipa servers is no longer
>> required and we would like to revert back to using certificates from
>> the freeipa self-signed CA. Is there a way to do so?
>
> This will request a new certificate using certmonger which will replace the 3rd party certificate and configure the renewal tracking. You may want to make a copy of the 3rd party cert and key just in case.
>
> ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/ipa.example.test-443-RSA -D `hostname` -D ipa-ca.example.test -C /usr/libexec/ipa/certmonger/restart_httpd -K HTTP/`hostname` -v -w
>
> If you aren't using ACME you can skip the SAN for ipa-ca.example.test
>
> Restart the httpd service once it is issued.
>
> Adjust to your hostname/domain as needed.
>
> rob
>
Dear Stephan,
thanks for your reply.
We are facing a similar issue (on cloudera CDH) and I wanted to ask you
how you
> removed the expired X3 CA and cross-signed X1 with `ipa-cacert-manage` (using the force flag),
I do not see force flag in my v. (4.6.4) of the command...
thanks for your help,
Gr
Hi,
Maybe I'm just missing something very trivial but I have trouble setting
user homedirs to a value of /home/%u instead of default /home/%d/%u for
users from AD (with established one-way trust).
We have AD server example.com and FreeIPA on idm-eu.example.com. Ubuntu
clients are joined to IPA without issues.
The only way I've achieved to change the homedir destination was to use
following statement in sssd.conf:
override_homedir = /home/%u
But with override_homedir all idview homedir overrides are ignored and
this is a problem for us.
I've tried playing with fallback_homedir and subdomain_homedir but
without any success (no change after sss_cache -E && systemctl restart
sssd && getent passwd myaduser1). It still points to
/home/example.com/myaduser1 (or to value of idview override).
What can I do to use custom default homedir path and to utilize idview
homedir overrides at the same time?
IPA server is on Centos8:
ipa-common-4.9.3-1
Ubuntu is on 20.04:
# ipa --version
VERSION: 4.8.6, API_VERSION: 2.236
Thank you.
Jan
When I started writing python scripts communicating with the IPA API
some years ago I used the python-freeipa library
(https://python-freeipa.readthedocs.io/en/latest/ ). When I revisited
one of my scripts today I was wondering why I was using python-freeipa
and not ipalib that comes with every freeipa-client installation.
My guess is that ipalib is the way to go because it comes directly from
you.
Is there any good reason for sticking with python-freeipa? (I doubt it...)
What are your thoughts?
Cheers,
Ronald
Dungan, Scott A. via FreeIPA-users wrote:
> Hi All
>
>
>
> After deploying FreeIPA with an embedded self-signed CA, the ipa servers
> were configured to use commercially signed, 3^rd party certificates for
> the HTTP service only. The directory server was left default. This was
> accomplished by importing the external CA and then the signed
> certificate, following the instructions on freeipa.org:
>
>
>
> ipa-cacert-manage -t C,, install InCommon_interm.cer
>
> ipa-certupdate
>
> ipa-server-certinstall --http /var/lib/ipa/private/httpd.key
> /var/lib/ipa/private/InCommon_signed.cer
>
> ipactl restart
>
>
>
> A commercially signed web certificate on the ipa servers is no longer
> required and we would like to revert back to using certificates from the
> freeipa self-signed CA. Is there a way to do so?
This will request a new certificate using certmonger which will replace
the 3rd party certificate and configure the renewal tracking. You may
want to make a copy of the 3rd party cert and key just in case.
ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k
/var/lib/ipa/private/httpd.key -p
/var/lib/ipa/passwds/ipa.example.test-443-RSA -D `hostname` -D
ipa-ca.example.test -C /usr/libexec/ipa/certmonger/restart_httpd -K
HTTP/`hostname` -v -w
If you aren't using ACME you can skip the SAN for ipa-ca.example.test
Restart the httpd service once it is issued.
Adjust to your hostname/domain as needed.
rob
Hi all,
I'm looking to implement OTP on FreeIPA, but would prefer not to keep
requesting users enter their OTP each login. In fact I get users to add
their public key to their profile when adding them to FreeIPA so they
can SSH to hosts using SSO auth. In the same way when they connect to a
(bastion) jumphost .bashrc checks if they have a valid Kerberos ticket
and issues kinit if they don't have one. What I'm after is the following:
* User connects to a jumphost and is prompted for their IPA password
and 2FA code on login. Checking for a valid Kerberos ticket in
.bashrc works as even if a user does certificate auth to the
jumphost the kinit will prompt for a password. Which is fine, as it
only happens when there's no valid Kerberos ticket.
* User connects through the jumphost (to other hosts, Kerberos and the
client certificate ensures that this is fully SSO as far as user
experience goes.
* A user should be prompted for a OTP (once) every 24 hours.
I want to add 2FA to this process, but only for obtaining the Kerberos
ticket, not for subsequent logins. So my questions:
* Will adding 2FA break the SSO and prompt a user for a OTP on each
connection they make to a host?
* If it does, is it possible to only prompt for a OTP on the first
connection made by the user. I trust Kerberos auth for SSO, I just
want to add 2FA to obtaining a valid Kerberos ticket.
Maybe I'm over thinking things, but I'd like to have a firm
understanding on how 2FA changes things before deploying it.
Thanks,
Djerk Geurts
Hi,
On my Centos 7 master there was this error message
[19/Nov/2021:11:16:11.863597190 +0100] - ERR - oc_check_allowed_sv - Entry "ipaUniqueID=b2211c08-4921-11ec-974b-509a4c9d3b10,cn=sudorules,cn=sudo,dc=example,dc=com" -- attribute "entryuuid" not allowed
[19/Nov/2021:11:16:26.331298112 +0100] - ERR - oc_check_allowed_sv - Entry "ipaUniqueID=b2211c08-4921-11ec-974b-509a4c9d3b10,cn=sudorules,cn=sudo,dc=example,dc=com" -- attribute "entryuuid" not allowed
[19/Nov/2021:11:16:45.264647201 +0100] - ERR - oc_check_allowed_sv - Entry "ipaUniqueID=b2211c08-4921-11ec-974b-509a4c9d3b10,cn=sudorules,cn=sudo,dc=example,dc=com" -- attribute "entryuuid" not allowed
The sudorule was add via the web-GUI on a Centos 8stream master.
The replication more or less succeeded, besides this error message. However,
* checkipaconsistency reports "LDAP Conflicts" (the Centos 7 master has count 1, the other masters have count 0)
* ipa-healthcheck reports an error too
[
{
"source": "ipahealthcheck.ds.replication",
"kw": {
"msg": "Replication conflict",
"glue": false,
"conflict": "Schema violation",
"key": "ipaUniqueID=b2211c08-4921-11ec-974b-509a4c9d3b10,cn=sudorules,cn=sudo,dc=ghs,dc=nl"
},
"uuid": "01d364fc-e48e-44bd-9ea8-63db1e800788",
"duration": "0.001689",
"when": "20211122070012Z",
"check": "ReplicationConflictCheck",
"result": "ERROR"
}
]
Any advise how to get rid of the error messages would be greatly appreciated.
--
Kees