FreeIPA on CentOS 7 fails with latest bind packages
by Jeremy Utley
Hello Everyone!
We have a pair of IPA servers running under CentOS 7 (I know, EOL is approaching, and we are working on migrating!). When we applied the latest patches this morning, the new bind packages were causing named-pkcs11 to core dump during ipa-server-upgrade. The new package versions were:
bind-9.11.4-26.P2.el7_9.16.x86_64
bind-dyndb-ldap-11.1-7.el7_9.1.x86_64.rpm
The error we saw is almost identical to what is documented at:
https://access.redhat.com/solutions/7065748
for RHEL8/9, but the recommended fixes did not help.
We rolled our installation back to the previous bind packages and everything works again. I don't think there's anyplace remaining to submit CentOS 7 bug reports, and I'm also not sure if this same issue would impact the remaining RHEL 7 installs, since we have no RHEL licensing. So I thought I would put it out on here, so at least others are aware of the issue!
16 hours, 13 minutes
Re: Create IPA user via LDAP
by Ronald Wimmer
On 08.01.24 17:58, Alexander Bokovoy wrote:
> On Пан, 08 сту 2024, Ronald Wimmer wrote:
>> On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:
>>> On 02.01.24 16:27, Rob Crittenden wrote:
>>>> Ronald Wimmer via FreeIPA-users wrote:
>>>>>
>>>>>
>>>>> On 14.12.23 14:42, Alexander Bokovoy wrote:
>>>>>> On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
>>>>>>> In our company we do have an IAM tool for user management. We
>>>>>>> need to
>>>>>>> create IPA users via this particular tool. I am aware of all IPA
>>>>>>> commands or API calls to create/modify or delete a user.
>>>>>>>
>>>>>>> As the tool does not support FreeIPA yet they asked if there is a
>>>>>>> way
>>>>>>> to manage users by using LDAP only. Could that work? What about
>>>>>>> attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?
>>>>>>
>>>>>> Learn about lifecycle management. This is your way of integrating
>>>>>> with
>>>>>> such tools bvy creating staged users:
>>>>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
>>>>>>
>>>>>
>>>>> I followed the instructions from the documentation.
>>>>>
>>>>> How could I possibly overcome
>>>>>
>>>>> Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
>>>>> ipa: ERROR: Constraint violation: pre-hashed passwords are not valid
>>>>>
>>>>> I need to set passwords from the external system.
>>>>
>>>> You need to enable migration mode (ipa config-mod --enable-migration
>>>> true).
>>>>
>>>> By default a pre-hashed password can only be set once: during the user
>>>> add operation.
>>>
>>> Ok. So this would not work for a password change. So if we need to
>>> set an initial password and change that particular password in some
>>> point in time the only feasible way is the IPA API, right?
>>>
>>> Can the immediate password expiration be overridden?
>>
>> As we have an upcoming please allow me to ask if I got the point here.
>>
>> I appreciate your support in this matter!
>>
>
> I was looking over the code. The only way to accept pre-hashed passwords
> is when they also have Kerberos keys set. This means you cannot use
> external LDAP modify/add for that as you cannot create the Kerberos key
> without knowing a Kerberos master key.
>
> So the only other option is to submit a clear-text password:
>
> userPassword: {CLEAR}text-password
>
> That will be accepted and if bind DN that performed this change is
> either a cn=Directory Manager or a one from the passsync managers, it
> would also not be marked for expiration immediately.
If I try to set the userPassword attribute to some value with an LDAP
browser and chose "plaintext" the value gets hashed immediately. I do
see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
I tried to enable migration mode and wanted to try it again but now I
cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true
Maximum username length: 32
Maximum hostname length: 64
Home directory base: /home
Default shell: /bin/sh
Default users group: ipausers
Default e-mail domain: ipatest.mydomain.at
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: True
Certificate Subject base: O=IPATEST.MYDOMAIN.AT
Password Expiration Notification (days): 4
Password plugin features: AllowNThash, KDC:Disable Last Success
SELinux user map order:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: MS-PAC, nfs:NONE
IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at
IPA master capable of PKINIT: tipa01.ipatest.mydomain.at,
tipa02.ipatest.mydomain.at
IPA CA servers: tipa01.ipatest.mydomain.at
IPA CA renewal master: tipa01.ipatest.mydomain.at
Domain resolution order: org.mydomain.at:ipatest.mydomain.at
[root@tipa01 ~]# ipa config-mod --enable-migration=false
ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may
provide more information, Minor (2529638972): KDC returned error string:
PROCESS_TGS
17 hours, 23 minutes
I am unable to install freeIPA server by dnf in Redhat Linux 8.1
by veck zuo
=> I am trying to deploy a freeIPA server in VM. Following the steps from https://www.freeipa.org/page/Quick_Start_Guide . I am unable to install the package by dnf .
VM:
[root@freeipa ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.10 (Ootpa)
[root@freeipa ~]# uname -r
4.18.0-372.9.1.el8.x86_64
[root@freeipa ~]#
[root@freeipa ~]# dnf search freeipa-server
Updating Subscription Management repositories.
Last metadata expiration check: 0:13:36 ago on Sun 16 Jun 2024 12:57:13 AM CST.
No matches found.
[root@freeipa ~]#
3 days, 1 hour
freeipa behind loadbalancer? is it doable?
by slek kus
Hi, I have placed a load balancer (using netfilter's LVS) before both freeipa servers (main and replica).
Trying to join a client pointing to this loadbalancer simply doesn't work. Firewall is tested and all needed ports are open and correctly forwarded to the freeipa nodes.
Also tried adding the lb dns rec to the existing DNS record types, such as ldap, kerberos, ns, txt etc..
Has anyone attempted freeipa invalid behind an LB? Is this a terrible idea and if possible does anyone have any pointers?
ADDING CLIENT RESULTS IN:
Using existing certificate '/etc/ipa/ca.crt'.
Skip idmlb.linux.redacted.invalid: LDAP server is not responding, unable to verify if this is an IPA server
Failed to verify that idmlb.linux.redacted.invalid is an IPA Server.
This may mean that the remote server is not up or is not reachable due to network or firewall settings.
Please make sure the following ports are opened in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information
DEBUG:
2024-06-13T14:18:36Z DEBUG stderr=
2024-06-13T14:18:36Z DEBUG Deleting invalidalid keytab: '/etc/krb5.keytab'.
2024-06-13T14:18:36Z WARNING Using existing certificate '/etc/ipa/ca.crt'.
2024-06-13T14:18:36Z DEBUG [IPA Discovery]
2024-06-13T14:18:36Z DEBUG Starting IPA discovery with domain=linux.redacted.invalid, servers=['idmlb.linux.redacted.invalid'], hostname=happyhost.infra.redacted.invalid
2024-06-13T14:18:36Z DEBUG Server and domain forced
2024-06-13T14:18:36Z DEBUG [Kerberos realm search]
2024-06-13T14:18:36Z DEBUG Kerberos realm forced
2024-06-13T14:18:36Z DEBUG [LDAP server check]
2024-06-13T14:18:36Z DEBUG Verifying that idmlb.linux.redacted.invalid (realm LINUX.redacted.invalid) is an IPA server
2024-06-13T14:18:36Z DEBUG Init LDAP connection to: ldap://idmlb.linux.redacted.invalid:389
2024-06-13T14:18:36Z DEBUG LDAP Error: cannot connect to 'ldap://idmlb.linux.redacted.invalid:389':
2024-06-13T14:18:36Z WARNING Skip idmlb.linux.redacted.invalid: LDAP server is not responding, unable to verify if this is an IPA server
2024-06-13T14:18:36Z DEBUG Discovery result: NO_LDAP_SERVER; server=None, domain=linux.redacted.invalid, kdc=idmlb.linux.redacted.invalid, basedn=None
2024-06-13T14:18:36Z DEBUG Validated servers:
2024-06-13T14:18:36Z ERROR Failed to verify that idmlb.linux.redacted.invalid is an IPA Server.
2024-06-13T14:18:36Z ERROR This may mean that the remote server is not up or is not reachable due to network or firewall settings.
3 days, 20 hours
Strange users search limit appeared
by Anton PalkoBrosov
I make some synchronization features with freeipa. For this i need to fetch users from LDAP db.
By default search limit is 2000 users both in GUI and API.
So i made modofications in freeipa configs
ldapmodify -x -D "cn=Directory Manager" -W -H ldap://localhost
dn: cn=config
changetype: modify
replace: nsslapd-sizelimit
nsslapd-sizelimit: 20000000
so all started to work fine, for starter there were just around 3000 users in db so it worked fine, returned all users.
then i started to generate new users to see perfomance of DB, so i used "pkey_only: true" in "user_find" command so when quantity of users reached 90k users it spend around 25sec to response, so ok its tolerable....
so all 90k+ users still returned by API
So issue happened when quantity of users reached around 100к+ users, so search limit shrinked to 49629 users
shrikage info started to add to responses
"count": 49629,
"truncated": true,
"messages": [
{
"type": "warning",
"name": "SearchResultTruncated",
"message": "Search result has been truncated: Configured administrative server limit exceeded",
"code": 13017,
"data": {
"reason": "Configured administrative server limit exceeded"
}
}
]
i do not do anything with freeipa server, just worked python script which generated users, script worked delicate and slow , he always waited for response from API that user created before creating another one user, so there were no high parallel overload on DB
so i searched for nsslapd-sizelimit again with command:
ldapsearch -x -D "cn=Directory Manager" -W -H ldap://localhost -b "cn=config" nsslapd-sizelimit
but is showed normally nsslapd-sizelimit: 20000000
so with settings all fine, it shows that number that i set
so what happened? Where freeipa get this strange limit in 49629 users and why? How to handle this? so projected size of LDAP DB is around 15 millons users
I tried to workaround this with python ldap-3 library in hope it make some more low-level requests without any limits, but via python script i have this limit too, so its totally global for all, UI, API and python API...
So how to remove this strange limit?
4 days, 20 hours
Strange user search result limits appeared
by Anton PalkoBrosov
I make some synchronization features with freeipa. For this i need to fetch users from LDAP db.
By default search limit is 2000 users both in GUI and API.
So i made modofications in freeipa configs
ldapmodify -x -D "cn=Directory Manager" -W -H ldap://localhost
dn: cn=config
changetype: modify
replace: nsslapd-sizelimit
nsslapd-sizelimit: 20000000
so all started to work fine, for starter there were just around 3000 users in db so it worked fine, returned all users.
then i started to generate new users to see perfomance of DB, so i used "pkey_only: true" in "user_find" command so when quantity of users reached 90k users it spend around 25sec to response, so ok its tolerable....
so all 90k+ users still returned by API
So issue happened when quantity of users reached around 100к+ users, so search limit shrinked to 49629 users
shrikage info started to add to responses
"count": 49629,
"truncated": true,
"messages": [
{
"type": "warning",
"name": "SearchResultTruncated",
"message": "Search result has been truncated: Configured administrative server limit exceeded",
"code": 13017,
"data": {
"reason": "Configured administrative server limit exceeded"
}
}
]
i do not do anything with freeipa server, just worked python script which generated users, script worked delicate and slow , he always waited for response from API that user created before creating another one user, so there were no high parallel overload on DB
so i searched for nsslapd-sizelimit again with command:
ldapsearch -x -D "cn=Directory Manager" -W -H ldap://localhost -b "cn=config" nsslapd-sizelimit
but is showed normally nsslapd-sizelimit: 20000000
so with settings all fine, it shows that number that i set
so what happened? Where freeipa get this strange limit in 49629 users and why? How to handle this? so projected size of LDAP DB is around 15 millons users
I tried to workaround this with python ldap-3 library in hope it make some more low-level requests without any limits, but via python script i have this limit too, so its totally global for all, UI, API and python API...
So how to remove this strange limit?
4 days, 22 hours
Strange user search result limits appeared
by Anton PalkoBrosov
I make some synchronization features with freeipa. For this i need to fetch users from LDAP db.
By default search limit is 2000 users both in GUI and API.
So i made modofications in freeipa configs
ldapmodify -x -D "cn=Directory Manager" -W -H ldap://localhost
dn: cn=config
changetype: modify
replace: nsslapd-sizelimit
nsslapd-sizelimit: 20000000
so all started to work fine, for starter there were just around 3000 users in db so it worked fine, returned all users.
then i started to generate new users to see perfomance of DB, so i used "pkey_only: true" in "user_find" command so when quantity of users reached 90k users it spend around 25sec to response, so ok its tolerable....
so all 90k+ users still returned by API
So issue happened when quantity of users reached around 100к+ users, so search limit shrinked to 49629 users
shrikage info started to add to responses
"count": 49629,
"truncated": true,
"messages": [
{
"type": "warning",
"name": "SearchResultTruncated",
"message": "Search result has been truncated: Configured administrative server limit exceeded",
"code": 13017,
"data": {
"reason": "Configured administrative server limit exceeded"
}
}
]
i do not do anything with freeipa server, just worked python script which generated users, script worked delicate and slow , he always waited for response from API that user created before creating another one user, so there were no high parallel overload on DB
so i searched for nsslapd-sizelimit again with command:
ldapsearch -x -D "cn=Directory Manager" -W -H ldap://localhost -b "cn=config" nsslapd-sizelimit
but is showed normally nsslapd-sizelimit: 20000000
so with settings all fine, it shows that number that i set
so what happened? Where freeipa get this strange limit in 49629 users and why? How to handle this? so projected size of LDAP DB is around 15 millons users
I tried to workaround this with python ldap-3 library in hope it make some more low-level requests without any limits, but via python script i have this limit too, so its totally global for all, UI, API and python API...
So how to remove this strange limit?
5 days, 21 hours
Certificate problem
by Yavor Marinov
Hello all,
I've tried to look over the list for the problem I have, but it seems I
can't find anything related. We are using FreeIPA 4.11 on Alma9 with
Letsencrypt certificates. Until now I didn't had issues renewing
certificates (using https://github.com/freeipa/freeipa-letsencrypt for
renewing certificates) but since last night's renewal I can't get in to
login into webui and can't enroll any new resources. The error i got from
webui is standart Login failed due to an unknown reason and there are no
errors in pki-tomcat. In apache's error logs the following error is
produced:
[Wed Jun 12 13:58:11.298021 2024] [wsgi:error] [pid 211427:tid 211669]
[remote 91.239.13.253:34362] ipa: INFO: 401 Unauthorized:
HTTPSConnectionPool(host='login.example.net', port=443): Max retries
exceeded with url: /ipa/session/cookie (Caused by
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: unable to get local issuer certificate
(_ssl.c:1129)')))
Trying with curl to reach some of the certificates with
curl https://login.example.net:443/ca/rest/certs/1
returns error "unable to get local issuer certificate". However, reaching
the IPA webui using Chrome doesn't return an error "ERROR_UNKNOWN_ISSUER"
but FireFox reports that the certificate is unknown.
I know this is a trivial problem, but since I'm using letsencrypt I'm a bit
worried since this is the first time having issues with certificates. The
same problem is present on our replica.
Any help would be much appreciated.
6 days
ipa-server upgrades not possible on RHEL 9 - samba-client-libs outdated
by Sam Morris
Hi folks. On a RHEL 9 system I'm getting:
# dnf upgrade
Updating Subscription Management repositories.
Last metadata expiration check: 3:01:24 ago on Tue Jun 11 05:37:06 2024.
Error:
Problem 1: cannot install the best update candidate for package
ipa-server-4.11.0-10.el9_4.x86_64
- nothing provides samba-client-libs >= 4.19.4-105.el9_4 needed by
ipa-server-4.11.0-15.el9_4.x86_64 from rhel-9-for-x86_64-appstream-rpms
Problem 2: [...]
etc.
Currently only the older version of samba-client-libs is available:
# dnf list samba-client-libs
Not root, Subscription Management repositories not updated
Last metadata expiration check: 8:22:10 ago on Tue Jun 11 00:17:42 2024.
Installed Packages
samba-client-libs.x86_64 4.19.4-104.el9
@rhel-9-for-x86_64-baseos-rpms
Available Packages
samba-client-libs.i686 4.19.4-104.el9
rhel-9-for-x86_64-baseos-rpms
I guess this will fix itself soon but I wanted to check on the chance
that I've managed to break something locally...
Thanks
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
6 days, 4 hours
Fedora 40/FreeIPA 4.12
by Jochen Kellner
Hi,
I've re-installed my test system with Fedora 40. ipa-healthcheck says:
{
"source": "ipahealthcheck.ipa.files",
"check": "TomcatFileCheck",
"result": "WARNING",
"uuid": "0cad1a21-d450-4c68-845f-e72a640af360",
"when": "20240610020014Z",
"duration": "0.000986",
"kw": {
"key": "_var_lib_pki_pki-tomcat_conf_ca_CS.cfg_mode",
"path": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg",
"type": "mode",
"expected": "0660",
"got": "0664",
"msg": "Permissions of /var/lib/pki/pki-tomcat/conf/ca/CS.cfg are too permissive: 0664 and should be 0660"
}
},
Otherwise the system seems to run fine. Might be a packaging problem...
Jochen
--
This space is intentionally left blank.
1 week
