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
5 days, 22 hours
pki-tomcatd service stopped
by Natxo Asenjo
hi,
after a botched update (https://access.redhat.com/solutions/7065748) and
rolling back the changes, this service will not start:
# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: STOPPED
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
1 service(s) are not running
in journalctl I found this stdout/stderr messages:
May 24 11:40:35 kdc1.sub.domain.tld named[27437]: zone sub.domain.tld/IN:
sending notifies (serial 1716543629)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: ERROR: Unable to
parse version number: "11.5.0"
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: Traceback (most
recent call last):
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/server/pkiserver.py", line 41, in
<module>
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
cli.execute(sys.argv)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/server/cli/__init__.py", line 145, in
execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
super().execute(args)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/cli/__init__.py", line 217, in execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
module.execute(module_args)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 144, in
execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: self.upgrade(
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 178, in
upgrade
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
upgrader.upgrade()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 481, in upgrade
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: versions =
self.versions()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 238, in versions
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: current_version
= self.get_current_version()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 341, in
get_current_version
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: current_version
= self.get_tracker().get_version()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 141, in get_version
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: return
pki.util.Version(version)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File
"/usr/lib/python3.9/site-packages/pki/util.py", line 613, in __init__
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: raise
Exception('Unable to parse version number: %s' % obj)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: Exception: Unable to
parse version number: "11.5.0"
May 24 11:40:35 kdc1.sub.domain.tld systemd[1]:
pki-tomcatd(a)pki-tomcat.service: Control process exited, code=exited,
status=1/FAILURE
May 24 11:40:35 kdc1.sub.domain.tld systemd[1]:
pki-tomcatd(a)pki-tomcat.service: Failed with result 'exit-code'.
May 24 11:40:35 kdc1.sub.domain.tld systemd[1]: Failed to start PKI Tomcat
Server pki-tomcat.
So it seems something is broken on this upgrade script. This is in in
almalinux 9.3
ipa-server-4.10.2-5.el9_3.alma.1.x86_64
I cannot upgrade because I get bitten by the named ldap thing, even though
the versions are newer.
I will create a replicat to a rhel host but first I need to get the CA up
and running obviously :-).
Any ideas?
Thanks!
--
regards,
natxo
--
--
Groeten,
natxo
2 weeks, 5 days
kpi-tomcatd failing to start
by girish f
I have IPA setup long back.
Some of the certificates expired. So i went back in time and then it's working super smooth.
When i did ipa-cert-fix --> error is Server-Cert not found
I renewed kerberos kdc.key kdc.crt.
But still it's failing to start the kpi_tomcatd. When i check status of kpi-tomcatd@kpi-tomcatd it shows running, but service starts to fail when
i come back to current time and restart ipactl restart.
need urgent help please
3 weeks
Remove bad replica nodes from list
by Satish Patel
Folks,
I am trying to build some replicas and somehow they failed but because they
are half baked they are stuck in master nodes and not letting me remove
them. I have tried all the options and don't know how to get rid of them.
I want to remove ldap-vx-010103-1.site5.example.com and
ldap-vx-010103-2.site5.example.com. I have removed them from topology and
from host and hostgroup ipaservers list but no luck. I have totally shut
down replicas nodes but still no luck. Are there any good ways to clean
them up?
[root@ldap-vx-010101-4 ~]# ipa-replica-manage list -v `hostname`
ldap-vx-010101-1.site5.example.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
ldap-vx-010101-2.site5.example.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
ldap-vx-010101-3.site5.example.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
ldap-vx-010101-5.site5.example.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
ldap-vx-010103-1.site5.example.com: replica
last init status: Error (0)
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (-1) Problem connecting to replica - LDAP
error: Can't contact LDAP server (connection error)
last update ended: 2024-05-11 10:30:33+00:00
ldap-vx-010103-2.site5.example.com: replica
last init status: Error (0) Total update succeeded
last init ended: 2024-05-10 20:35:02+00:00
last update status: Error (-1) Problem connecting to replica - LDAP
error: Can't contact LDAP server (connection error)
last update ended: 1970-01-01 00:00:00+00:00
ldap-vx-010103-3.site5.example.com: replica
last init status: Error (0) Total update succeeded
last init ended: 2024-05-10 21:14:53+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2024-05-16 01:58:02+00:00
3 weeks
[freeipa][ca] Changing IP of CA replica
by Satish Patel
Folks,
Is changing the IP address possible for a CA replica? I am having a hard
time creating new CA replicas so to buy sometime I would like to change the
IP address of the CA replica if it's easy.
I have external DNS, we don't use freeIPA based DNS and all certs are
self-sign.
~S
3 weeks, 3 days
when 2FA enabled, with 2 factor prompt asking doesn't work
by seojeong kim
on server side, ipauserauthtype set as password + otp.
[root@xxxxxx /]# ipa user-show ereen-test --raw | grep ipauserauthtype
ipauserauthtype: password
ipauserauthtype: otp
And I added new configuration in /etc/ssh/sshd_config on my host which is ipa client is installed.
GSSAPIAuthentication yes
And /etc/sssd/sssd.conf
[prompting/password/sshd]
password_prompt = password :
[prompting/2fa/sshd]
first_prompt = first pwd :
second_prompt = second otp :
But all the time, when I try ssh login with ereen-test, the prompt asks "password :"
I expect 2 factor asking as I configured like below
first_prompt :
second_prompt :
Is there other configuration should I set more ?
3 weeks, 4 days
vulnerability on port 8443 reported by Nessus scanner- caSigningCert cert-pki-ca
by Polavarapu Manideep Sai
Hi Team,
I have a vulnerability on port 8443 reported by Nessus scanner
I have third-party certificate already installed at LDAP and Apache services
I have root and intermediate certificate also installed on pki-tomcat service as shown below
The certificate "caSigningCert cert-pki-ca" which is causing this vulnerability
Any Suggestions to overcome this issue?
[root@aaa01 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'caSigningCert cert-pki-ca' |egrep -i 'Issuer:|Subject:'
Issuer: "CN=Certificate Authority,O=IPA.EXAMPLE.COM"
Subject: "CN=Certificate Authority,O=IPA.EXAMPLE.COM"
[root@aaa01 ~]# certutil -L -d /etc/dirsrv/slapd-IPA-EXAMPLE-COM/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
CN=*.IPA.EXAMPLE.COM u,u,u
IPA.EXAMPLE.COM IPA CA CT,C,C
NSS Certificate DB:NSS Certificate DB:CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com\, Inc.,L=Scottsdale,ST=Arizona,C=US CT,C,C
CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com\, Inc.,L=Scottsdale,ST=Arizona,C=US CT,C,C
OU=Go Daddy Class 2 Certification Authority,O=The Go Daddy Group\, Inc.,C=US CT,C,C
[root@aaa01 ~]#
[root@aaa01 ~]#
[root@aaa01 ~]# certutil -L -d /etc/pki/pki-tomcat/alias/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu
ocspSigningCert cert-pki-ca u,u,u
Server-Cert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
NSS Certificate DB:NSS Certificate DB:CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com\, Inc.,L=Scottsdale,ST=Arizona,C=US CT,C,C
CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com\, Inc.,L=Scottsdale,ST=Arizona,C=US CT,C,C
OU=Go Daddy Class 2 Certification Authority,O=The Go Daddy Group\, Inc.,C=US CT,C,C
Scanning Report and Solution Given:
8443 SSL Certificate Cannot Be Trusted The SSL certificate for this service cannot be trusted.
8443 SSL Self-Signed Certificate "The SSL certificate chain for this service ends in an unrecognized
self-signed certificate."
Solution:
Purchase or generate a proper SSL certificate for this service.
Regards
Sai
________________________________
DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.
3 weeks, 4 days
Possible to adjust generated salt size for CRYPT-SHA512 passwords?
by Jason Borden
Greetings all,
I'm pretty new to FreeIPA and would like to know if I can adjust the salt size generated by FreeIPA when using CRYPT-SHA512 as the passwordStorageScheme.
After modifying the cn=config to use CRYPT-SHA512 passwords by default, new passwords are correctly generated using CRYPT-SHA512, however the size of the salt is tiny (only 2 base64 chars or about 12bits). I'd really like to configure FreeIPA to generate a larger salt, but I'm not sure if that's possible.
Just for background on why I've chosen to use CRYPT-SHA512 instead of the standard PBKDF2-SHA256 is because I intend to sync the password hashes in FreeIPA to a system we have that neither supports LDAP or Kerberos: postfixadmin. Postfixadmin supports CRYPT-SHA512 hashes but not PBKDF2-SHA256.
Thanks,
Jason
3 weeks, 5 days
Recommended resolv.conf / hosts file
by David Harvey
Hi FreeIPA users,
I nested this under a related topic before (subject: Replica
re-initialization failing Replication bind with GSSAPI auth failed: LDAP
error 49 (Invalid credentials) () ) but it was admittedly a bit off topic...
Is configuring resolv.conf with the single resolver 127.0.0.1 the blessed /
recommended setup?
We've had some chicken and egg situations recently where dirsrv being sad
has broken local DNS resolution, and then krb behaviours and lookup for the
other IPA servers has been impaired as a result.
If solely using local bind / loopback in resolv.conf is the recommended
state, should we be putting the other IPA servers in /etc/hosts or anything
to make sure they can identify one and other in the case of dirsrv sadness?
Thanks in advance,
David
3 weeks, 5 days
FreeIPA - Need help with Expired Certificate
by azeem
Hello!
I have inherited a FreeIPA server, and upon checking the certificate list with getcert list, it shows that the certificate is already expired. Does anyone know how to renew it? And coz of this issue, I am not able to enroll any any clients. Any help would be appreciated.
Request ID '20160825909273':
status: CA_UNREACHABLE
ca-error: Server at https://test.domain.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://test.domain.com:443/ca/eeca/ca/profileSubmitSSLClient': (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.).
stuck: no
key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-TEST-DOMAIN-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-TEST-DOMAINCOM/pwdfile.txt'
certificate: type=NSSDB,location='/etc/dirsrv/slapd-TEST-DOMAIN-COM',nickname='Server-Cert',token='NSS Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TEST-DOMAIN-COM
subject: CN=test.domain.com,O=TEST.DOMAIN.COM
expires: 2023-12-18 15:52:08 UTC
principal name: ldap/test.domain.com(a)TEST.DOMAIN.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv TEST.DOMAIN.COM
track: yes
auto-renew: yes
3 weeks, 6 days
