Trust between FreeIPA servers
by freeipaquestion
Hi all,
I was wondering if it would be possible to create a trust relation between two FreeIPA servers. I've read a lot about a trust relation between FreeIPA and Microsoft AD, however I'd like to set up a trust between FreeIPA and FreeIPA.
The use case I'm trying to cover: I'm maintaining multiple environments at different clients and I'd like to be able to log in with my credentials in systems of clients while separating users at the client. Ideally I'd set up a FreeIPA for mycomany.com and make a trust with a FreeIPA for myclient.com. The users at mycompany.com should be able to log in on systems that are enrolled on myclient.com. The users of the client are stored in the IPA server of myclient.com.
Thanks in advance for your help!
Sent with [ProtonMail](https://protonmail.com/) Secure Email.
2 years, 5 months
Revert web cert from 3rd party to internal ca
by Dungan, Scott A.
Hi All
After deploying FreeIPA with an embedded self-signed CA, the ipa servers were configured to use commercially signed, 3rd 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?
Regards,
Scott
2 years, 5 months
External CA causing issues on Ubuntu Clients
by Russ Long
I am using SSL issued by external CA (Godaddy) for my FreeIPA servers. I have installed the cert using the IPA cert installation tools, however on Ubuntu 20.04 clients, I receive the following error:
```
Setting up ca-certificates (20210119~20.04.2) ...
Updating certificates in /etc/ssl/certs...
sed: can't read /usr/local/share/ca-certificates/ipa-ca/CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US 0.crt: No such file or directory
```
This error is seen when trying to perform package updates on these servers. The only workaround I have found so far is to uninstall the freeipa client, run my package updates, then re-install the client. This is obviously not an ideal solution.
Here's the commands used to install the certs:
ipa-cacert-manage -p {{ ipa_dirman_pass }} -n GoDaddyBundle2019 -t C,, install /opt/ipa-ssl/godaddy.ca.crt
ipa-server-certinstall -w -d /opt/ipa-ssl/ipa.domain.key /opt/ipa-ssl/ipa.domain.crt --dirman-password={{ ipa_dirman_pass }} --pin=''
ipa-certupdate
Certs and all other clients appear to work without issue.
IPA Server version:
ipa-server-4.6.8-5.el7.centos.7.x86_64
IPA Client version:
freeipa-client 4.8.6-1ubuntu2
2 years, 5 months
Cannot access IPA Web UI since the last update on RHEL 8
by Mathieu Baudier
Hello,
On (self-supported) RHEL 8, since the last update, we are not able to login to the Web UI anymore.
IPA package version is: 4.9.2-4.module+el8.4.0+11156+94d209c1
In Firefox we get:
IPA Error 903: InternalError
an internal error has occurred
and then:
Web UI got in unrecoverable state during "metadata" phase.
In the httpd error log we see:
[Sat Nov 06 07:05:05.971287 2021] ipa: ERROR: non-public: KeyError: 'ipatrustedaddomainrange'
[Sat Nov 06 07:05:05.971311 2021] Traceback (most recent call last):
[Sat Nov 06 07:05:05.971315 2021] File "/usr/lib/python3.6/site-packages/ipaserver/rpcserver.py", line 397, in wsgi_execute
[Sat Nov 06 07:05:05.971317 2021] result = command(*args, **options)
[Sat Nov 06 07:05:05.971320 2021] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 471, in __call__
[Sat Nov 06 07:05:05.971322 2021] return self.__do_call(*args, **options)
[Sat Nov 06 07:05:05.971324 2021] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 499, in __do_call
[Sat Nov 06 07:05:05.971327 2021] ret = self.run(*args, **options)
[Sat Nov 06 07:05:05.971329 2021] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 821, in run
[Sat Nov 06 07:05:05.971331 2021] return self.execute(*args, **options)
[Sat Nov 06 07:05:05.971334 2021] File "/usr/lib/python3.6/site-packages/ipaserver/plugins/internal.py", line 126, in execute
[Sat Nov 06 07:05:05.971336 2021] (o.name, json_serialize(o)) for o in self.api.Object()
[Sat Nov 06 07:05:05.971339 2021] File "/usr/lib/python3.6/site-packages/ipaserver/plugins/internal.py", line 127, in <genexpr>
[Sat Nov 06 07:05:05.971341 2021] if o is self.api.Object[o.name]
[Sat Nov 06 07:05:05.971343 2021] File "/usr/lib/python3.6/site-packages/ipalib/util.py", line 106, in json_serialize
[Sat Nov 06 07:05:05.971346 2021] return json_serialize(obj.__json__())
[Sat Nov 06 07:05:05.971348 2021] File "/usr/lib/python3.6/site-packages/ipaserver/plugins/baseldap.py", line 889, in __json__
[Sat Nov 06 07:05:05.971351 2021] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses)
[Sat Nov 06 07:05:05.971353 2021] File "/usr/lib64/python3.6/site-packages/ldap/schema/subentry.py", line 378, in attribute_types
[Sat Nov 06 07:05:05.971355 2021] object_class = self.sed[ObjectClass][object_class_oid]
[Sat Nov 06 07:05:05.971368 2021] KeyError: 'ipatrustedaddomainrange'
In order to analyse, we configured /etc/ipa/server.conf as:
[global]
debug=true
and restarted IPA. And it is sometimes working again (not clear whether this is thanks to this file, or because of the restart), but then after a while it is failing again.
We ran ipa-server-upgrade manually (successful).
All ipa services are up, Kerberos login works fine.
ipa-healthcheck does not return any warning or error.
We are *not* using AD integration at all.
The package ipa-server-trust-ad is not installed.
Does this ring a bell to you?
How should we analyse further?
Thanks in advance for your help!
Mathieu
2 years, 5 months
cannot find name for group ID x when logging in
by Mark Johnson
Got my authentication working and I populated my directory with users and groups and assigned group memberships accordingly. I wasn't getting this issue originally, but now I'm suddenly getting the "cannot find name for group ID 10000" when I log in to my test server.
The group with GID 10000 is a POSIX enabled group I created called "users" that all user accounts are a member of. My user account is a member of a handful of other POSIX enabled groups. Another of these groups is called "admins" and has a GID of 10001. There's also "serveradmins" (GID -> 500) and "devserveraccess" (GID -> 501). If I issue an "id", it shows all of these groups, but doesn't show the names of GID 10000 and GID 10001, eg
$ id
uid=1069(markj) gid=10000 groups=10000,2(daemon),500(serveradmins),501(devserveraccess),10001 context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
However, if I do a "getent group" I can see all of these groups and their members, eg
serveradmins:*:500:markj,user4
devserveraccess:*:501:markj,user1,user4
users:*:10000:user1,user2,markj,user4
admins:*:10001:admin,markj
I have a suspicion as to what might be at play here. Keep in mind that I've set up the new directory using all the same info (usernames, groups, UIDs, GIDs etc) from the existing 389 DS directory. Just looking through this, I see we have a user with a UID of 10000, and another with a UID of 10001. We don't have any with UID of 500 or 501. If I look at the full "getent group" output, it shows the above groups I've already mentioned but also lists all the users, including the two with ID 10000 and 10001. I'm suspecting this is causing some kind of conflict. If I change my user account's GID to 100 (the normal built-in local 'users' group), I can log in without getting this error. The only issue with this is we've been running on this old 389 directory since well before I joined the company so there are many years worth of home directories and user files with the group owner of '10000' which is now not going to show a group name. Not sure if this is going to cause any issues dow
n the line, probably only an aesthetics thing.
2 years, 5 months
Fail to restart ipa server after ipa packages updates
by MERCIER Jonathan
Dear,
After a package update from ipa-server-4.9.2-4.module+el8.4.0+589+9650b94f.x86_64 to ipa-server-4.9.2-4.module+el8.4.0+664+1636a961.x86_64
I am unable to restart ipa server services indeed the command /usr/sbin/ipa-server-upgrade fail as it is not able to reach 'https://ipa.somewhere.com:8443/ca/rest/account/login' . Indeed the dns service is on the same server and is started by ipa services.
below a piece of log
Thanks for your help
Best regards
--------
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
Unexpected error - see /var/log/ipaupgrade.log for details:
NetworkError: cannot connect to 'https://ipa.somewhere.com:8443/ca/rest/account/login': [Errno 113] No route to host
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information
See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade again
Stopping ipa-dnskeysyncd Service
Stopping ipa-otpd Service
Stopping pki-tomcatd Service
Stopping ipa-custodia Service
Stopping httpd Service
Stopping named Service
Stopping kadmin Service
Stopping krb5kdc Service
Stopping Directory Service
----
2 years, 5 months
RA Agent certificate authorisation fails – how to debug?
by Tomasz Torcz
Hi,
I've encountered some authentication problems with my FreeIPA
installation, which I've traced to RA Agent certification auth problems.
I've done typical steps to verify certs in LDAP and hit a wall.
Please suggest further steps.
My setup is 2 masters on Fedora 34:
freeipa-server-4.9.6-2.fc34.x86_64
pki-base-10.10.6-1.fc34.noarch
Steps I've done:
First I noticed problems when enabling ACME:
$ ipa-acme-manage enable
Failed to authenticate to CA REST API
The ipa-acme-manage command failed.
This is caused by authentication failure (401 return code), which
I confirmed using curl:
$ curl -X POST https://kaitain.pipebreaker.pl:8443/acme/enable --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key
<!doctype html><html lang="en"><head><title>HTTP Status 401 – Unauthorized</title><style type="text/css">body
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line
{height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP
Status 401 – Unauthorized</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Description</b> The request has not been applied because
it lacks valid authentication credentials for the target resource.</p><hr class="line" /><h3>Apache Tomcat/9.0.52</h3></body></html>
Errors from catalina.out:
02-Oct-2021 16:29:39.618 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ExternalAuthenticationValve.invoke ExternalAuthenticationValve: authType: null
02-Oct-2021 16:29:39.618 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ExternalAuthenticationValve.invoke ExternalAuthenticationValve: principal: null
02-Oct-2021 16:29:39.620 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate PKIAuthenticator: Authenticate with client certificate authentication
02-Oct-2021 16:29:39.620 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ProxyRealm.authenticate Authenticating certificate chain:
02-Oct-2021 16:29:39.621 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ProxyRealm.authenticate - CN=IPA RA,O=PIPEBREAKER.PL
02-Oct-2021 16:29:39.621 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.ProxyRealm.authenticate - CN=Certificate Authority,O=PIPEBREAKER.PL
02-Oct-2021 16:29:39.624 INFO [https-jsse-nio-8443-exec-6] com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate PKIAuthenticator: Result: false
I've made sure that /var/lib/ipa/ra-agent.pem is the same as in LDAP.
$ openssl x509 -in /var/lib/ipa/ra-agent.pem -noout -text | grep Serial
Serial Number: 105 (0x69)
$ ldapsearch -o ldif_wrap=no -D "cn=directory manager" -W -b o=ipaca "(uid=ipara)"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <o=ipaca> with scope subtree
# filter: (uid=ipara)
# requesting: ALL
#
# ipara, people, ipaca
dn: uid=ipara,ou=people,o=ipaca
description: 2;105;CN=Certificate Authority,O=PIPEBREAKER.PL;CN=IPA RA,O=PIPEBREAKER.PL
userCertificate;binary:: <SNIPPED>
cn: ipara
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: cmsuser
usertype: agentType
sn: ipara
uid: ipara
userstate: 1
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Then SNIPPED portion is the same data as in /var/lib/ipa/ra-agent.pem.
This is the same certificate; serial number matches, too.
Certificate is NOT expired:
$ openssl x509 -in /var/lib/ipa/ra-agent.pem -noout -dates
notBefore=Jun 16 04:34:42 2021 GMT
notAfter=Jun 6 04:34:42 2023 GMT
What should I do next to resolve this authentication issue?
--
Tomasz Torcz Morality must always be based on practicality.
tomek(a)pipebreaker.pl — Baron Vladimir Harkonnen
2 years, 5 months
Re: Unable to communicate with CMS (403)
by Sander Steffann
Hi,
> I can confirm that I ran in this issue on CentOS Stream 8 and this solution works.
Same here. I spent a day searching for the cause. I was misled by this Red Hat article: https://access.redhat.com/solutions/4796941 which mentions the same error message, so I spent most of my day debugging TLS :)
After finding this thread the problem was solved in minutes. Thanks to everybody!
Cheers,
Sander
2 years, 5 months
Re: Samba Freeipa Authentication
by Per Qvindesland
Great many thanks, that worked really well.One quick question, I need to add the SRV records after running ad-trust-install to the DNS but the main WIndows AD corporate DNS is not very useful for those type of SRV records so I would like to install ipa's DNS add on and i found this article https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide... I am wondering it's a smart thing to do or should I just setup a bind DNS server instead?RegardsPerOn 1 Nov 2021, at 13:08, Alexander Bokovoy <abokovoy(a)redhat.com> wrote:On ma, 01 marras 2021, Per Qvindesland via FreeIPA-users wrote:Hi I am busy setting up Samba with Freeipa authentication, I have been following [1]https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_... tired it on both Centos 7 and Ubuntu 20.04 but both is failing the authentication with: root@no-oslh-smb2:/home/luser# smbclient -K -L 10.93.150.74 -U pqvindes Enter PROXDYNAMICS\pqvindes's password: session setup failed: NT_STATUS_LOGON_FAILURE The local and the remote address is the hosts own IP address 10.93.150.74 which I find a bit odd. Does anyone have any suggestions on how to get it working?Please use Fedora 32+ or RHEL 8.2+ and follow official documentation:https://access.redhat.com/documentation/en-us/red_hat_enter... / Alexander BokovoySr. Principal Software EngineerSecurity / Identity Management EngineeringRed Hat Limited, Finland
2 years, 5 months