Problem with added host to freeipa with AD Trust setup
by cdth@gmx.net
Hi!
I am experiencing strange behaviour with a host which is added to an IPA instance. The IPA instance is working as it should and I can't see any problems there. There is a Trust established to an AD domain.
The AD domain is in the form of example.com whereas the IPA domain is ipa.example.com domain. However the domain names of the hosts are host-ipa.example.com and client-ipa.example.com (and not host-ipa.ipa.example.com). As already said this works fine for the IPA server itself but for the client I am experiencing weird behaviour.
I can add the client to the IPA domain by joining via ipaclient-install script and log on is working during the first minutes, but after some time a login via ssh public key is not possible anymore. When I look into the log files I can see that a connection to the directory server fails with the error message "Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/EXAMPLE.COM(a)IPA.EXAMPLE.COM not found in Kerberos database)]" which seems to be the root cause for my problem as it should be krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM to my knowledge.
I already tried a hint from this thread https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah... which tells to check the domain_realm mapping in /etc/krb5.conf (due to includes the [domain_realm] resides in /var/lib/sss/pubconf/krb5.include.d/domain_realm_ipa_example_com and indeed the mapping looks wrong to me:
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
[capaths]
EXAMPLE.COM = {
IPA.EXAMPLE.COM = EXAMPLE.COM
}
IPA.EXAMPLE.COM = {
EXAMPLE.COM = EXAMPLE.COM
}
I believe this should look like:
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
[capaths]
EXAMPLE.COM = {
IPA.EXAMPLE.COM = IPA.EXAMPLE.COM
}
IPA.EXAMPLE.COM = {
EXAMPLE.COM = EXAMPLE.COM
}
But changing the file does not help as after restarting sssd the file is overwritten again with the former version.
Any hints are greatly appreciated!
(the domain names are redacted to protect the innocent ;-) )
Best regards,
Thomas
1 year, 1 month
Cannot authenticate using Kerberos after upgrade to 4.10.1
by Gianluca Amato
Hi all,
I have a FreeIPA installation with three servers on CentOS Stream 9. Recently, I upgraded one server from FreeIPA 4.10.0 to 4.10.1. After the upgrade, kinit <user> fails in the new server for all users, with the only exception of the admin user. The following happens:
1) In the command shell, I type "kinit studente" (or any other user but admin)
2) I enter the correct password
3) The result is "kinit: Generic error (see e-text) while getting initial credentials"
Kerberos authentication still works correctly on the servers which are still on 4.10.0. LDAP authentication works correctly everywhere.
If I check the /var/log/krb5kdc.log, I notice the following:
Mar 14 13:35:13 ipa1.labeconomia.unich.it krb5kdc2868: AS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 10.1.68.199: HANDLE_AUTHDATA: studente(a)LABECONOMIA.UNICH.IT for krbtgt/LABECONOMIA.UNICH.IT(a)LABECONOMIA.UNICH.IT, No such file or directory
So the problem seems this "No such file or directory" during the HANDLE_AUTHDATA phase, but I have no idea what file it is looking for. This error only appears if I type the correct password. In case of wrong password, I get a standard "Preauthentication failed" error.
Note also that "admin" is the only user with a SID (attribute "ipaNTSecurityIdentifier" in LDAP), which is required for generating Kerberos tickets with PACs. Is it possible the new FreeIPA insists in generating PACs? In case, is it possible to disable this behavior ?
Thanks for any help,
--gianluca
1 year, 1 month
Help with importing Asterisk LDAP Schema into FreeIPA Server.
by r0 nam1
Hi,
I'm currently attempting to run my asterisk instance and testing instance in realtime mode with the database being my FreeIPA instance. To do this I've looked at every thread and determined that the OpenLDAP structure Asterisk Provides and the 389 structure FreeIPA uses are different. I am not sure how different, so I have no clue how to translate it.
I also have two ways of importing it, (I think), either with ldapadd, or by moving the ldif file to a certain directory and restarting the service, issue with that second approach is that I'm not sure what will happen if the ldif file isn't valid. I'll post what the asterisk source provides:
https://wiki.asterisk.org/wiki/display/AST/LDAP+Realtime+Driver
The ldif and schema file are both on that page, I'm not looking for somebody to translate if it's to much work, but I simply want to know how to. Seems like a valuable skill to have.
1 year, 1 month
Publicly resolvable DNS
by Francis Augusto Medeiros-Logeay
Hi,
I am considering using my current FreeIPA set-up - which has only .local
domains, to be authoritative for a domain name. Therefore, I might open
the port 53 to allow external queries.
Is it a reasonable ok thing to do? And is there a way to use ACL's to
block queries that are not for that publicly-resoveable domain name?
Best,
Francis
--
Francis Augusto Medeiros-Logeay
Oslo, Norway
1 year, 1 month
Free IPA sub CA and 8192 keys
by Алексей Иванов
Greetings,
During installation process I used following pki_override.cfg file
[DEFAULT]
pki_admin_key_algorithm=SHA512withRSA
pki_admin_key_size=8192
pki_audit_signing_key_algorithm=SHA512withRSA
pki_audit_signing_key_size=8192
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA512withRSA
pki_ssl_server_key_algorithm=SHA512withRSA
pki_ssl_server_key_size=8192
pki_sslserver_signing_algorithm=SHA512withRSA
pki_subsystem_key_algorithm=SHA512withRSA
pki_subsystem_signing_algorithm=SHA512withRSA
pki_subsystem_key_size=8192
[CA]
pki_ca_signing_key_size=8192
pki_ca_signing_key_algorithm=SHA512withRSA
pki_ca_signing_signing_algorithm=SHA512withRSA
pki_ocsp_signing_key_algorithm=SHA512withRSA
pki_ocsp_signing_key_size=8192
pki_ocsp_signing_signing_algorithm=SHA512withRSA
[KRA]
pki_storage_key_algorithm=SHA512withRSA
pki_storage_key_size=8192
pki_storage_signing_algorithm=SHA512withRSA
pki_transport_key_algorithm=SHA512withRSA
pki_transport_key_size=8192
pki_transport_signing_algorithm=SHA512withRSA
[OCSP]
pki_ocsp_signing_key_algorithm=SHA512withRSA
pki_ocsp_signing_key_size=8192
pki_ocsp_signing_signing_algorithm=SHA512hRSA
This lead to the following error when I'm trying to add subCA
Request failed with status 400: Non-2xx response from CA REST API: 400.
Failed to issue CA certificate. Final status: rejected. Additional info:
Key Parameters 1024,2048,3072,4096,nistp256,nistp384,nistp521 Not Matched
By default we have three certificate profiles caIPAserviceCert,
KDCs_PKINIT_Certs, IECUserRoles but changing them does not fix this error.
Could you please tell me where I can find a subCA certificate template?
Regards,
Alex Ivanov.
1 year, 2 months
Different results with search in replicas
by danila kuzovlev
Hi, I'm trynig to create centrlized authorization for my services with freeipa cluster in differnet locations. For some reasons I use base search in cn=compat tree for mapping users, but in different replcias result of same ldapsearch quiestions is different:
ldapsearch -h X.X.X.X -p 389 -b "cn=some_group,cn=groups,cn=compat,dc=example,dc=com" -s base -D "uid=binddn,cn=users,cn=accounts,dc=example,dc=com" -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <cn=some_group,cn=groups,cn=compat,dc=example,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
ldapsearch -h Y.Y.Y.Y -p 389 -b "cn=some_group,cn=groups,cn=compat,dc=example,dc=com" -s base -D "uid=binddn,cn=users,cn=accounts,dc=example,dc=com" -W
# extended LDIF
#
# LDAPv3
# base <cn=some_group,cn=groups,cn=compat,dc=example,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
# some-group, groups, compat, example.com
dn: some_group,cn=groups,cn=compat,dc=example,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: ipaexternalgroup
objectClass: top
gidNumber: 12345678
memberUid: user2
memberUid: user1
ipaAnchorUUID:: OklQQToyMS1zY2hvb2wucnU6YjI2ZTNkNjQtYWI5ZC0xMWVkLWE5NDUtMDA1MD
U2YWIxMDNl
cn: some_group
But, if I make search with "Subtree" cope to the first one, I can see entries in answer:
ldapsearch -h X.X.X.X -p 389 -b "cn=some_group,cn=groups,cn=compat,dc=example,dc=com" -s sub -D "uid=binddn,cn=users,cn=accounts,dc=example,dc=com" -W
# extended LDIF
#
# LDAPv3
# base <cn=some_group,cn=groups,cn=compat,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# some-group, groups, compat, example.com
dn: some_group,cn=groups,cn=compat,dc=example,dc=com
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: ipaexternalgroup
objectClass: top
gidNumber: 12345678
memberUid: user2
memberUid: user1
ipaAnchorUUID:: OklQQToyMS1zY2hvb2wucnU6YjI2ZTNkNjQtYWI5ZC0xMWVkLWE5NDUtMDA1MD
U2YWIxMDNl
cn: some_group
I have 4 ipa-servers with vesrions 4.9.6 and 4.9.10.
This result I can see with a only one replica, with 4.9.6 vesrion. I try delete topology segment, reinstall ipa-replica - but it doesnt work.
Thanks.
1 year, 2 months
v4.6.8->v4.10.1 Replica Install | CA Configuration Section | Admin Login Failing
by Paulson McIntyre
Hey,
I'm trying to create a replica from an older FreeIPA server to a more
modern one. The eventual plan being to remove the very old one and use the
new one as the primary. Then new replicas would be created off it.
Running into a problem though during the CA Configuration phase when it
tries to create the admin user, or rather verify it.
This thread
<https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...>
might be related as well as RedHat Bugzilla – Bug 2151071
<https://bugzilla.redhat.com/show_bug.cgi?id=2151071>.
Details on the issue, environment, and troubleshooting performed so
far are posted
here <https://www.gpmidi.net/node/162> as well as copy/pasted below.
-Paulson
The ProblemOverview
Can't create a new replica of an older FreeIPA server (v4.6.8 on c7) to a
new FreeIPA server (v4.9 on f36 and v4.10 on f37). The error is during the
`Configuring certificate server (pki-tomcatd)` phase.
Example ipa-replica-install error
# kinit <MY PERSONAL ADMIN USERNAME>
# ipa-replica-install --setup-adtrust --setup-ca --setup-dns
--no-forwarders --skip-conncheck --add-sids
...
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
[1/30]: creating certificate server db
[2/30]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 11 seconds elapsed
Update succeeded
[3/30]: creating ACIs for admin
[4/30]: creating installation admin user
Unable to log in as uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca on
ldap://ipam.i.gpmidi.net:389
[hint] tune with replication_wait_timeout
[error] NotFound: uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca did
not replicate to ldap://ipam.i.gpmidi.net:389
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca did not replicate to
ldap://ipam.i.gpmidi.net:389
The ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information
From Installer Log
2023-03-01T18:01:02Z DEBUG [4/30]: creating installation admin user
2023-03-01T18:01:02Z DEBUG Waiting 30 seconds for
uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca to appear on
ldap://ipam.i.gpmidi.net:389
2023-03-01T18:01:32Z ERROR Unable to log in as
uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca on
ldap://ipam.i.gpmidi.net:389
2023-03-01T18:01:32Z INFO [hint] tune with replication_wait_timeout
2023-03-01T18:01:32Z DEBUG Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/ipaserver/install/service.py",
line 686, in start_creation
run_step(full_msg, method)
File "/usr/lib/python3.11/site-packages/ipaserver/install/service.py",
line 672, in run_step
method()
File "/usr/lib/python3.11/site-packages/ipaserver/install/dogtaginstance.py",
line 789, in setup_admin
raise errors.NotFound(
ipalib.errors.NotFound: uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca
did not replicate to ldap://ipam.i.gpmidi.net:389
2023-03-01T18:01:32Z DEBUG [error] NotFound:
uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca did not replicate to
ldap://ipam.i.gpmidi.net:389
2023-03-01T18:01:32Z DEBUG The ipa-replica-install command failed,
exception: NotFound: uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca did
not replicate to ldap://ipam.i.gpmidi.net:389
While Waiting For User Sync/Validation...
*tl;dr The user seems to exist on both sides!*
[root@ipa0 ~]# ldapsearch -x -D "cn=Directory Manager" -W -b
"uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca"
ldap://ipam.i.gpmidi.net:389
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca> with scope subtree
# filter: (objectclass=*)
# requesting: ldap://ipam.i.gpmidi.net:389
#
# admin-ipa0.i.gpmidi.net, people, ipaca
dn: uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
[root@ipa0 ~]# ldapsearch -x -D "cn=Directory Manager" -W -b
"uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca" ldap://localhost
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca> with scope subtree
# filter: (objectclass=*)
# requesting: ldap://localhost
#
# admin-ipa0.i.gpmidi.net, people, ipaca
dn: uid=admin-ipa0.i.gpmidi.net,ou=people,o=ipaca
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
------------------------------
The EnvironmentSource
Distro: CentOS 7.9.2009
FreeIPA: 4.6.8
TargetOriginally
Distro: Fedora Server 36
FreeIPA: 4.9.11
Later
Distro: Fedora Server 37
FreeIPA: 4.10.1
Install CommandsStep 1 - Client
ipa-client-install --ssh-trust-dns --mkhomedir --realm=I.GPMIDI.NET
--ntp-pool=0.pool.ntp.org --force-join --enable-dns-updates --subid
--hostname=ipa0.i.gpmidi.net --ntp-server=1.pool.ntp.org
Step 2 - kinit
kinit <MY PERSONAL USER>
Step 3 - Replica Install
ipa-replica-install --setup-adtrust --setup-ca --setup-dns
--no-forwarders --skip-conncheck --add-sids
Sometimes the `--debug` flag was also used.
The installer would ask about trusted domain support - answered "no" via no
entry unless noted otherwise.
Enable trusted domains support in slapi-nis? [no]:
Cleanup Commands
Used after a failure to reset the environment.
Step 1 - Uninstall
/usr/sbin/ipa-server-install --uninstall
Step 2 - Validated Server Removed
Browsed to https://ipam.i.gpmidi.net/ipa/ui/#/e/server/search and validated
that the new server, ipa0, wasn't listed. Deleted if it was.
------------------------------
Related Links
- FreeIPA Users thread
<https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...>
- Red Hat Bugzilla – Bug 2151071
<https://bugzilla.redhat.com/show_bug.cgi?id=2151071>
------------------------------
Attempted Fixes
Changed Replication Wait Time
Created ` /etc/ipa/installer.conf` (see below) and changed the time in
seconds.
# cat /etc/ipa/installer.conf
[global]
replication_wait_timeout=30
Result
30s = No change
300s = No change
600s = No change
*Left at 30s for further testing - keeps it quick - provides more than
enough time since my ldap db is small. *
Update Source IPA Box From C7 To C8Result
Upgrade from c7 to c8 failed badly. Might try again later.
Update Source IPA Box 389 `root` Password Hash Type
# /usr/bin/pwdhash -D /etc/dirsrv/slapd-YOUR-DOMAIN-NET -s
PBKDF2_SHA256 '<Current DirSrv Root Password>'
{PBKDF2_SHA256}xxxxxxxxxxxxxxxxxxxxxxxx
Result
No change
Updated Target IPA Box To Fedora Server 37
Updated target IPA box from f36 to f37. This changed the IPA version from
4.9.11 to 4.10.1.
Result
No change
Changing Password Storage Scheme On Source
# dsconf -D "cn=Directory Manager" -W ldaps://ipam.i.gpmidi.net config
replace passwordStorageScheme=PBKDF2_SHA256
Enter password for cn=Directory Manager on ldaps://ipam.i.gpmidi.net:
<ENTERED ROOT PW>
Successfully replaced "passwordStorageScheme"
Result
No change
Trusted Domains Answer = Yes
Answered 'yes' to trusted domains.
Enable trusted domains support in slapi-nis? [no]: yes
Result
No change
Restarted IPA On Source
Since the `dsconf` change above to the password storage scheme the IPA
server on the source box hasn't been restarted. Restarted it via...
# ipactl restasrt
Result
No change
1 year, 2 months
Configuration of server on DO droplet in Docker container and clients behind router's NAT
by Georgiy Odisharia
Hi there,
I know that it is not secure but I have exposed to the internet FreeIPA instance for uniform logging between all my machines. They're reside at my home network behind OpenWRT-based router (behind NAT). Public IP address of router is getting via ISP's DHCP.
I want to properly set up FreeIPA server in Docker container running on the DigitalOcean droplet, set up DNS entries in DigitalOcean panel, and properly set up client for allowing LDAP authentication (sssd.conf, krb5.conf and so on).
I don't know where to start and debug so if anybody will help me in general I would be highly appreciated.
1 year, 2 months
Re: FreeIPA Replica Install Issue
by Rob Crittenden
Jerome Talbert via FreeIPA-users wrote:
> Hello,
>
>
>
> We had an issue with one of replicas and decided to remove it from the
> topology and run the ipa-server-install –uninstall command on the
> replica. I also went through and removed all the SRV records related to
> the replica.
>
>
>
> The idea was to reinstall the same server as replica again using the
> command:
>
> ipa-replica-install --setup-dns --setup-ca --principal=admin
> --password='############' --no-forwarders
>
>
>
> When I try to run the command, I get the following error message:
>
> ipapython.admintool: ERROR Cannot install replica of a server of
> higher version ((u'00000004', u'00000006', u'00000008', '*final')) than
> the local version ((u'00000004', u'00000006', u'00000006', '*final'))
>
> ipapython.admintool: ERROR The ipa-replica-install command failed.
> See /var/log/ipareplica-install.log for more information
>
>
>
> Any ideas what might be going on here? Do I have something left-over on
> the replica that needs to be cleaned up manually first?
As the message says, you are trying to create a new server using a lower
version than the remote server. A higher local version is allowed for
upgrades but not the other way around. (4.6.8 remote, 4.6.6 local).
Updating the IPA packages on your replica should fix it.
rob
1 year, 2 months