Unable to install FreeIPA when crypto-policy = FUTURE
by Jeffrey van Pelt
Hi all,
Currently I'm setting up a FreeIPA instance on EL8 with the
crypto-policy set to FUTURE.
When running the ipa-server-install program, it errors out when setting
up the PKI infrastructure.
Below is the command I ran:
```
ipa-server-install --pki-config-override /root/freeipa_pki_override.cfg
--setup-adtrust -p Banana123! -a Banana123! -r EXAMPLE.COM -U
```
As this command already shows, I already have some PKI override settings
to ensure all created keys are 4096 bits long:
```
[CA]
pki_ca_signing_key_size=4096
[DEFAULT]
pki_admin_key_size=4096
pki_audit_signing_key_size=4096
pki_sslserver_key_size=4096
pki_subsystem_key_size=4096
```
And even despite these settings, the command errors out giving me the
message as below:
```
..truncated..
[22/28]: enabling CA instance
[23/28]: migrating certificate profiles to LDAP
[24/28]: importing IPA certificate profiles
[error] NetworkError: cannot connect to 'https://ipa.lbhr.htm.lan:8443/ca/rest/account/login': [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:3542)
cannot connect to 'https://ipa.lbhr.htm.lan:8443/ca/rest/account/login': [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:3542)
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
```
So _some_ certificate _somewhere_ is not strong enough, but I can't find
which one it is and how to ensure it's strengthened sufficiently.
When I check the log file it shows basically the same message (except
with a lot of Python stacktraces with 'NetworkError')
When I revert the crypto-policy back to DEFAULT the command as shown
above will succeed.
Anyone have a clue? :)
Cheers!
--
Kind regards,
Jeff
1 year, 5 months
Deletion from distribution list
by Guillermo Colmena
Hi I would like to be removed from the distribution list. Let me know if
there is anything I can do.
Best regards,
Guillermo
1 year, 5 months
ipahealth keeps complaining even after re-initialize
by Kees Bakker
Hi,
This morning we ran into a problem after updating 386-base to 1.4.4.17 (hoping to solve a trimming [1] issue).
The ns-slapd server ended up in a deadlock so I had to revert.
Since then we have ipahealthcheck reporting CRITICAL "is not in synchronization" errors. Also, in one of the replica's there is a message "Incremental update failed and requires administration action". Although I'm the administrator myself I wasn't quite sure what to do. Somewhere I read that I should do a re-initialize. One of the three replica's/masters is still behaving normal (I hope). So I took that one as the source for the re-initialize.
I did do bot commands ipa-replica-manage and ipa-csreplica-manage with re-initialize. Both commands succeeded.
However, ipahealth check keeps complaining. I would like to know where else I should look to figure out the problem.
[
{
"source": "ipahealthcheck.ds.replication",
"check": "ReplicationCheck",
"result": "CRITICAL",
"uuid": "d44af6bf-f7e4-44de-b9c6-f32398ecf7f9",
"when": "20211018104930Z",
"duration": "0.103066",
"kw": {
"key": "DSREPLLE0001",
"items": [
"Replication",
"Agreement"
],
"msg": "The replication agreement (linge.example.com-to-iparep4.example.com) under \"dc=example,dc=com\" is not in synchronization."
}
},
{
"source": "ipahealthcheck.ds.replication",
"check": "ReplicationCheck",
"result": "CRITICAL",
"uuid": "239ad7db-8067-4623-b950-5237bef711f6",
"when": "20211018104930Z",
"duration": "0.103075",
"kw": {
"key": "DSREPLLE0001",
"items": [
"Replication",
"Agreement"
],
"msg": "The replication agreement (metorotte.example.com) under \"dc=example,dc=com\" is not in synchronization."
}
},
{
"source": "ipahealthcheck.ds.replication",
"check": "ReplicationCheck",
"result": "CRITICAL",
"uuid": "b5fc5f97-08cb-4d26-88cf-33dc04f8498f",
"when": "20211018104930Z",
"duration": "0.103077",
"kw": {
"key": "DSREPLLE0001",
"items": [
"Replication",
"Agreement"
],
"msg": "The replication agreement (catorotte.example.com) under \"o=ipaca\" is not in synchronization."
}
},
{
"source": "ipahealthcheck.ds.replication",
"check": "ReplicationCheck",
"result": "CRITICAL",
"uuid": "e633752c-6d5e-4fb7-91e2-218cb514dd61",
"when": "20211018104930Z",
"duration": "0.103078",
"kw": {
"key": "DSREPLLE0001",
"items": [
"Replication",
"Agreement"
],
"msg": "The replication agreement (linge.example.com-to-iparep4.example.com) under \"o=ipaca\" is not in synchronization."
}
}
]
[1] https://github.com/389ds/389-ds-base/pull/4895
--
Kees
1 year, 5 months
firewall rules for AD trust
by iulian roman
Hello everybody,
I have an Idm setup configured with AD trust. I would like to know if the systems in DMZ need to have firewall ports opened only for IPA servers or they need to access AD domain controllers as well ? Apparently, only with the rules for the IPA servers the authentication does not work.
Thanks,
iulian
1 year, 5 months
Re: Problems after replacing SSL certificates
by Muhammed Ali Yeter
Hello, I’ve been suffocating the same problem. I applied ipa-server-certinstall without adding ca first. I applied your steps and added my ca.crt to /etc/ipa/ca.crt and /etc/ipa/nssdb with certutil, after than I run ipa-certupdate and it fails again.
[root@xxx ~]# certutil -d sql:/etc/ipa/nssdb/ -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Xxx IPA CA CT,C,C
globalsign CT,C,C
After this I ran ipa-certupdate and it says
cannot connect to 'any of the configured servers’: …. (List of my ipaservers goes here)
The ipa-certupdate command failed.
Should I do this process for all servers, or I am missing something? Related to this problem I am having login failure at the web ui. Would it work if I created a new db and added my GlobalSign ca there? Do I need the self signed ipa ca?
Thanks.
1 year, 5 months
FreeIPA trust with Samba AD DC - It possible in 2021
by Jakub Novak
Hi.
Is possible create trust between FreeIPA (v. 4.9.6) and Samba AD DC (v. 4.13.5)?
I'm tried create trust via this command:
ipa -d -v trust-add --type ad --two-way=true ad.idp.t.dom --admin Administrator --password
(same command working correctly with Microsoft AD, but i need with Samba AD DC)
but allways I'm getting this error:
ipa: ERROR: an internal error has occurred
Is it even possible to create trust between them? What do I need to do?
Thanks
1 year, 5 months
ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Start tag expected, '<' not found, line 1, column 1)
by Natxo Asenjo
hi,
I have a lab test with fedora 34 (latest patches) and everything works ok
except the CA,
# ipa -d cert-find
ipa: DEBUG: Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa: DEBUG: Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
ipa: DEBUG: Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
ipa: DEBUG: importing all plugin modules in
ipaclient.remote_plugins.schema$af90c5da...
ipa: DEBUG: importing plugin module
ipaclient.remote_plugins.schema$af90c5da.plugins
ipa: DEBUG: importing all plugin modules in ipaclient.plugins...
ipa: DEBUG: importing plugin module ipaclient.plugins.automember
ipa: DEBUG: importing plugin module ipaclient.plugins.automount
ipa: DEBUG: importing plugin module ipaclient.plugins.ca
ipa: DEBUG: importing plugin module ipaclient.plugins.cert
ipa: DEBUG: importing plugin module ipaclient.plugins.certmap
ipa: DEBUG: importing plugin module ipaclient.plugins.certprofile
ipa: DEBUG: importing plugin module ipaclient.plugins.dns
ipa: DEBUG: importing plugin module ipaclient.plugins.hbacrule
ipa: DEBUG: importing plugin module ipaclient.plugins.hbactest
ipa: DEBUG: importing plugin module ipaclient.plugins.host
ipa: DEBUG: importing plugin module ipaclient.plugins.idrange
ipa: DEBUG: importing plugin module ipaclient.plugins.internal
ipa: DEBUG: importing plugin module ipaclient.plugins.location
ipa: DEBUG: importing plugin module ipaclient.plugins.migration
ipa: DEBUG: importing plugin module ipaclient.plugins.misc
ipa: DEBUG: importing plugin module ipaclient.plugins.otptoken
ipa: DEBUG: importing plugin module ipaclient.plugins.otptoken_yubikey
ipa: DEBUG: importing plugin module ipaclient.plugins.passwd
ipa: DEBUG: importing plugin module ipaclient.plugins.permission
ipa: DEBUG: importing plugin module ipaclient.plugins.rpcclient
ipa: DEBUG: importing plugin module ipaclient.plugins.server
ipa: DEBUG: importing plugin module ipaclient.plugins.service
ipa: DEBUG: importing plugin module ipaclient.plugins.sudorule
ipa: DEBUG: importing plugin module ipaclient.plugins.topology
ipa: DEBUG: importing plugin module ipaclient.plugins.trust
ipa: DEBUG: importing plugin module ipaclient.plugins.user
ipa: DEBUG: importing plugin module ipaclient.plugins.vault
ipa: DEBUG: found session_cookie in persistent storage for principal '
admin(a)L.EXAMPLE.ORG', cookie:
'ipa_session=MagBearerToken=oPsa86TucvUeZr9Ci3U1%2bRngbEyOxqkT55jYVP7d0%2b8nRDN2oemtH9vhs%2f1t8Skcz7uP0mbPdH2%2fnVYD8hdqtG0LMeml%2blPGNJjjJCEaQY0%2fjESuTTwACqY56q%2bWVXcfYIi22z0jjS%2foo7edWI0VvSi1OFcPMYiGAjCneS2uRxzFbXKtNeHcviqhRYubdy%2fOHJ5R34QJSZdiNXsDc0CAHA%3d%3d'
ipa: DEBUG: setting session_cookie into context
'ipa_session=MagBearerToken=oPsa86TucvUeZr9Ci3U1%2bRngbEyOxqkT55jYVP7d0%2b8nRDN2oemtH9vhs%2f1t8Skcz7uP0mbPdH2%2fnVYD8hdqtG0LMeml%2blPGNJjjJCEaQY0%2fjESuTTwACqY56q%2bWVXcfYIi22z0jjS%2foo7edWI0VvSi1OFcPMYiGAjCneS2uRxzFbXKtNeHcviqhRYubdy%2fOHJ5R34QJSZdiNXsDc0CAHA%3d%3d;'
ipa: DEBUG: trying https://kdc.l.example.org/ipa/session/json
ipa: DEBUG: Created connection context.rpcclient_140261006164032
ipa: DEBUG: raw: cert_find(None, version='2.243')
ipa: DEBUG: cert_find(None, version='2.243')
ipa: DEBUG: [try 1]: Forwarding 'cert_find/1' to json server '
https://kdc.l.example.org/ipa/session/json'
ipa: DEBUG: New HTTP connection (kdc.l.example.org)
ipa: DEBUG: Destroyed connection context.rpcclient_140261006164032
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Start tag expected, '<' not found, line 1, column 1)
In apache that is the error as well, in pki I see this:
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: Searching
for certificates
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: PKIService:
Request class: CertSearchRequest
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: PKIService:
Request format: application/xml
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: PKIService:
XML request:
<?xml version='1.0' encoding='UTF-8'?>
<CertSearchRequest><serialNumberRangeInUse>true</serialNumberRangeInUse><subjectInUse>false</subjectInUse><matchExactly>false</matchExactly><revokedByInUse>false</revokedByInUse><revokedOnInUse>false</revokedOnInUse><revocationReasonInUse>false</revocationReasonInUse><issuedByInUse>false</issuedByInUse><issuedOnInUse>false</issuedOnInUse><validNotBeforeInUse>false</validNotBeforeInUse><validNotAfterInUse>false</validNotAfterInUse><validityLengthInUse>false</validityLengthInUse><certTypeInUse>false</certTypeInUse></CertSearchRequest>
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: Search
filter: (certstatus=*)
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: Searching ou=certificateRepository, ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: filter: (certStatus=*)
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=11,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: Search
results: 11
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: Searching ou=certificateRepository, ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: filter: (certStatus=*)
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=1,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=2,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=3,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=4,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=5,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=6,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=7,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=8,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=9,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=10,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO:
DBVirtualList: dn: cn=11,ou=certificateRepository,ou=ca,o=ipaca
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: PKIService:
Response format: application/json
2021-10-15 19:40:14 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: PKIService:
Response class: CertDataInfos
The xml request looks ok (valid xml).
Googling finds some bugs with mod_deflate, but turning it off breaks httpd.
Any idea how to fix it??
Regards,
Natxo
--
--
Groeten,
natxo
1 year, 5 months
nsswitch sudoers sssd vs files priority
by Nathanaël Blanchet
Hello,
I noticed that "sudoers files" was default prior over "sudoers sssd"
into "/usr/share/authselect/default/sssd/nsswitch.conf" when registering
a client.
Sudoers is the only item to be files prior, all other items are sssd prior:
passwd: sss files systemd {exclude if "with-custom-passwd"}
group: sss files systemd {exclude if "with-custom-group"}
netgroup: sss files {exclude if "with-custom-netgroup"}
automount: sss files {exclude if "with-custom-automount"}
services: sss files {exclude if "with-custom-services"}
sudoers: files sss {include if "with-sudo"}
Is there a reason to keep files priority for sudoers while the client is
registered to a domain, and is intended to be first controlled by sssd?
--
Nathanaël Blanchet
Supervision réseau
SIRE
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5
Tél. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
blanchet(a)abes.fr
1 year, 5 months
User in AD not found by IPA
by Marc Boorshtein
We added a new account to AD that has a domain trust with FreeIPA. This
one user is having an issue where IPA can't find him. The user is in the
same OU as other users that work fine. The user is unlocked
(userAccountControl is 512) and the userprincipalname is set. When I try
to add the user to an id view or an external group IPA gives me the error
"trusted domain object not found" . Not really sure where to look next to
figure out what's wrong. We see the user when we make LDAP calls to AD.
Thanks
Marc
1 year, 5 months
Freeipa-client not available for debian bullseye
by ahmed zakraoui
Hello,
OK I know that there were an old discussion about this but still today, after the release of bullseye 11.1 the freeipa-client package is still not available.
We are using Centos 8 as FreeIPA masters so my question here is only about freeipa-client.
From what I can see here, Freeipa-client is only available for buster & sid
https://packages.debian.org/search?keywords=freeipa-client
To be honest with you this is the first time I see something like this.
What to do if our servers are using buster instead of bullseye? When the freeipa-client will be available for bullseye? (And will it be available for bullseye)
Thanks !
1 year, 5 months