How to use ipa-dsu
by Duarte Petiz
Hello freeipa users!
I'm trying to follow the guide that is available here: https://freeipa.readthedocs.io/en/latest/designs/disable-stale-users.html about ipa-dsu.
I was trying to do a dry-run in order to check what it really does on my env but the package seems to not be present.
I'm using the freeipa-server:rocky-9 docker image.
root@prod-us-freeipa:~# docker exec -ti ipa_freeipa_1 bash
[root@prod-us-freeipa /]# ipa-dsu --dry-run
bash: ipa-dsu: command not found
What could I do?
Regards
2 weeks, 4 days
KDC Self Signed Certificate Creation
by Mark Selby
My company has 6 FreeIPA servers across 3 different locations. Five of the six servers are ok, but one we could not login to. The error messages pointed to the expired certificate located at `/var/kerberos/krb5kdc/kdc.crt`
My question is how do I "properly" renew or recreate this certificate. I have been able to renew it with the command listed below - but the renewed cert does not have the same characteristics as the other certs. The existing ones all see to be self signed with the specified profile while my new one does not have these features. It seems to be working Ok but it would great to understand how to generate this cert correctly. All is any help is greatly appreciated.
The servers that work all display the following with using getcert list -f /var/kerberos/krb5kdc/kdc.crt
Request ID '20191003181545':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: SelfSign
issuer: CN=ipa01.sub1.acme.org,O=ACME.ORG
subject: CN=ipa01.sub1.acme.org,O=ACME.ORG
expires: 2022-08-09 22:06:33 UTC
principal name: krbtgt/ACME.ORG(a)ACME.ORG
certificate template/profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
Using the local-getcert start-tracking command below gets me an updated cert but it is not self signed and does not have the specified profile.
local-getcert start-tracking \
-k /var/kerberos/krb5kdc/kdc.key \
-f /var/kerberos/krb5kdc/kdc.crt \
-T KDCs_PKINIT_Certs \
-C /usr/libexec/ipa/certmonger/renew_kdc_cert
Request ID '20220117193849':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: local
issuer: CN=Certificate Authority,O=ACME.ORG
subject: CN=vipa06.sub3.acme.org,O=ACME.ORG
expires: 2024-01-18 17:32:20 UTC
principal name: krbtgt/ACME.ORG(a)ACME.ORG
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
3 weeks, 4 days
How to prevent non-admin users of FreeIPA from reading the list of users in the web interface?
by cdknight
When a user signs in to FreeIPA, I do not want them to be able to view the list of users in my LDAP server under the "Active users" link. I still want them to be able to administer self-service, so they can reset their password, add OTP tokens, etc. How would I go about doing this? The users will only be able to access the web interface, so it doesn't matter whether they can access it from other sources.
2 months
"Credential cache is empty" error preventing certmonger from renewing a host's certificate
by Sam Morris
I've got an IPA client on which certmonger is unable to renew a
certificate.
Here are the log messages from certmonger...
2023-06-20 08:24:49 [622035] Certificate submission attempt complete.
2023-06-20 08:24:49 [622035] Child status = 2.
2023-06-20 08:24:49 [622035] Child output:
"Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is >
"
2023-06-20 08:24:49 [622035] Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more infor>
Here's the tracking request, nothing looks out of the ordinary to me...
# getcert list -i 20220519165212
Number of certificates and requests being tracked: 2.
Request ID '20220519165212':
status: MONITORING
ca-error: Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cre.
stuck: no
key pair storage: type=FILE,location='/etc/cockpit/ws-certs.d/51-myhost.key'
certificate: type=FILE,location='/etc/cockpit/ws-certs.d/51-myhost.crt'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
subject: CN=myhost.ipa.example.com,O=IPA.EXAMPLE.COM
issued: 2023-03-25 16:52:45 UTC
expires: 2023-06-23 16:52:45 UTC
dns: myhost.ipa.example.com
principal name: host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
In order to rule out a problem with ipa5, I used 'ipactl' to stop
everything on it, then re-ran 'getcert resubmit -i 20220519165212'. In
the subsequent output of 'getcert list -i 20220519165212' I saw the same
error message displayed but with the name of a different IPA server. So
I don't think this is a problem with a particular IPA server.
Next I extracted the CSR data from
'/var/lib/certmonger/requests/20220519165212' to a file, authenticated
as host/myhost.ipa.example.com (with 'kinit -k') and then ran 'ipa
cert-request host.req --principal=host/myhost.ipa.example.com', which
worked!
So perhaps the problem is with certmonger, or with the way in which it
interacts with the IPA server that differs from simply running 'ipa
cert-request' as I did manually.
I also tried to look for logs on the server side, but I didn't find
anything very useful. /var/log/httpd/access_log has:
192.168.0.4 - - [20/Jun/2023:13:21:53 +0000] "POST /ipa/json HTTP/1.1" 401 2719
192.168.0.4 - host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [20/Jun/2023:13:21:53 +0000] "POST /ipa/json HTTP/1.1" 200 526
So it looks like certmonger is having no problem authenticating to
ipaapi. httpd is logging:
$ journalctl -u httpd -e
Jun 20 13:21:56 [121899]: GSSAPI client step 1
Jun 20 13:21:56 [121899]: GSSAPI client step 1
Jun 20 13:21:57 [121899]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
So is looks like ipaapi might be having trouble using Kerberos as a
client?
I added KRB5_TRACE=/var/lib/httpd/krb5.trace to httpd.service's
Environment= and restarted it, then re-ran 'getcert resubmit' on the
tracking request. I got these messages:
[124285] 1687270136.437160: Initializing FILE:/tmp/krb5cc-httpd with default princ HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM
[124285] 1687270136.437161: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> Encrypted/Credentials/v1@X-GSSPROXY: in FILE:/tmp/krb5cc-httpd
[124285] 1687270136.437163: Retrieving HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> Encrypted/Credentials/v1@X-GSSPROXY: from FILE:/tmp/krb5cc-httpd with result: 0/Success
[124285] 1687270136.437165: Initializing FILE:/run/ipa/ccaches/host~myhost.ipa.example.com@IPA.EXAMPLE.COM-h3azdl with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
[124285] 1687270136.437166: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> Encrypted/Credentials/v1@X-GSSPROXY: in FILE:/run/ipa/ccaches/host~myhost.ipa.example.com@IPA.EXAMPLE.COM-h3azdl
No errors there either. I set KRB5_TRACE=/var/lib/gssproxy/krb5.trace in
gssproxy.service's Environment= and got:
[124798] 1687270460.854044: Resolving unique ccache of type MEMORY
[124798] 1687270460.854045: Initializing MEMORY:GJanRRF with default princ HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270460.854046: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:GJanRRF
[124798] 1687270460.854047: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:GJanRRF
[124798] 1687270460.854048: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:GJanRRF
[124798] 1687270460.854049: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:GJanRRF
[124798] 1687270460.854052: Destroying ccache MEMORY:GJanRRF
[124798] 1687270460.854054: Resolving unique ccache of type MEMORY
[124798] 1687270460.854055: Initializing MEMORY:Cn5E8Va with default princ HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270460.854056: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:Cn5E8Va
[124798] 1687270460.854057: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:Cn5E8Va
[124798] 1687270460.854058: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:Cn5E8Va
[124798] 1687270460.854059: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:Cn5E8Va
[124798] 1687270460.854062: Destroying ccache MEMORY:Cn5E8Va
[124798] 1687270460.854064: Resolving unique ccache of type MEMORY
[124798] 1687270460.854065: Initializing MEMORY:8e5DNHy with default princ HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270460.854066: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:8e5DNHy
[124798] 1687270460.854067: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:8e5DNHy
[124798] 1687270460.854068: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:8e5DNHy
[124798] 1687270460.854069: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:8e5DNHy
[124798] 1687270460.854071: Decrypted AP-REQ with server principal HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM: aes256-cts/E0A2
[124798] 1687270460.854072: AP-REQ ticket: host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM, session key aes256-cts/1952
[124798] 1687270460.854073: Negotiated enctype based on authenticator: aes256-cts
[124798] 1687270460.854074: Authenticator contains subkey: aes256-cts/2098
[124798] 1687270460.854075: Resolving unique ccache of type MEMORY
[124798] 1687270460.854076: Initializing MEMORY:FX6Yqgq with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270460.854077: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:FX6Yqgq
[124798] 1687270460.854078: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:FX6Yqgq
[124798] 1687270460.854079: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:FX6Yqgq
[124798] 1687270460.854080: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:FX6Yqgq
[124798] 1687270460.854081: Storing config in MEMORY:FX6Yqgq for : proxy_impersonator: HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270460.854082: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:FX6Yqgq
[124798] 1687270460.854083: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:FX6Yqgq
[124798] 1687270460.854085: Creating AP-REP, time 1687270460.725581, subkey aes256-cts/BB66, seqnum 668121546
[124798] 1687270461.005570: Destroying ccache MEMORY:FX6Yqgq
[124798] 1687270461.005573: Destroying ccache MEMORY:8e5DNHy
[124798] 1687270461.005575: Resolving unique ccache of type MEMORY
[124798] 1687270461.005576: Initializing MEMORY:NmnNwyD with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270461.005577: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:NmnNwyD
[124798] 1687270461.005578: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:NmnNwyD
[124798] 1687270461.005579: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:NmnNwyD
[124798] 1687270461.005580: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:NmnNwyD
[124798] 1687270461.005581: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:NmnNwyD
[124798] 1687270461.005582: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:NmnNwyD
[124798] 1687270461.005585: Destroying ccache MEMORY:NmnNwyD
[124798] 1687270461.005587: Resolving unique ccache of type MEMORY
[124798] 1687270461.005588: Initializing MEMORY:gUnl8Xt with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270461.005589: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:gUnl8Xt
[124798] 1687270461.005590: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:gUnl8Xt
[124798] 1687270461.005591: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:gUnl8Xt
[124798] 1687270461.005592: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:gUnl8Xt
[124798] 1687270461.005593: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:gUnl8Xt
[124798] 1687270461.005594: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:gUnl8Xt
[124798] 1687270461.005597: Destroying ccache MEMORY:gUnl8Xt
[124798] 1687270461.005599: Resolving unique ccache of type MEMORY
[124798] 1687270461.005600: Initializing MEMORY:wBGblf3 with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270461.005601: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:wBGblf3
[124798] 1687270461.005602: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:wBGblf3
[124798] 1687270461.005603: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:wBGblf3
[124798] 1687270461.005604: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:wBGblf3
[124798] 1687270461.005605: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:wBGblf3
[124798] 1687270461.005606: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:wBGblf3
[124798] 1687270461.005609: Destroying ccache MEMORY:wBGblf3
[124798] 1687270461.005611: Resolving unique ccache of type MEMORY
[124798] 1687270461.005612: Initializing MEMORY:4uHf47g with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270461.005613: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:4uHf47g
[124798] 1687270461.005614: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:4uHf47g
[124798] 1687270461.005615: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:4uHf47g
[124798] 1687270461.005616: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:4uHf47g
[124798] 1687270461.005617: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:4uHf47g
[124798] 1687270461.005618: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:4uHf47g
[124798] 1687270461.005621: Destroying ccache MEMORY:4uHf47g
[124798] 1687270461.005623: Resolving unique ccache of type MEMORY
[124798] 1687270461.005624: Initializing MEMORY:9LUdBez with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270461.005625: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:9LUdBez
[124798] 1687270461.005626: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:9LUdBez
[124798] 1687270461.005627: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:9LUdBez
[124798] 1687270461.005628: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:9LUdBez
[124798] 1687270461.005629: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:9LUdBez
[124798] 1687270461.005630: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:9LUdBez
[124798] 1687270461.005634: Initializing MEMORY:cred_allowed_0x7f85d9152380 with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
[124798] 1687270461.005635: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:cred_allowed_0x7f85d9152380
[124798] 1687270461.005636: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:cred_allowed_0x7f85d9152380
[124798] 1687270461.005637: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM(a)X-CACHECONF: in MEMORY:cred_allowed_0x7f85d9152380
[124798] 1687270461.005638: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:cred_allowed_0x7f85d9152380
[124798] 1687270461.005639: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:cred_allowed_0x7f85d9152380
[124798] 1687270461.005640: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:cred_allowed_0x7f85d9152380
[124798] 1687270461.005641: Destroying ccache MEMORY:cred_allowed_0x7f85d9152380
[124798] 1687270461.005644: Getting credentials host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> ldap/ipa5.ipa.example.com@ using ccache MEMORY:9LUdBez
[124798] 1687270461.005645: Retrieving host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from MEMORY:9LUdBez with result: -1765328243/Matching credential not found
[124798] 1687270461.005646: Retrieving host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> ldap/ipa5.ipa.example.com@ from MEMORY:9LUdBez with result: -1765328243/Matching credential not found
[124798] 1687270461.005647: Retrying host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> ldap/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM with result: -1765328243/Matching credential not found
[124798] 1687270461.005648: Retrieving host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM from MEMORY:9LUdBez with result: 0/Success
[124798] 1687270461.005649: Getting credentials HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM using ccache MEMORY:9LUdBez
[124798] 1687270461.005650: Retrieving host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from MEMORY:9LUdBez with result: -1765328243/Matching credential not found
[124798] 1687270461.005651: Retrieving HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM from MEMORY:9LUdBez with result: 0/Success
[124798] 1687270461.005652: Get cred via TGT krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM after requesting ldap/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM (canonicalize on)
[124798] 1687270461.005653: Generated subkey for TGS request: aes256-cts/FBB4
[124798] 1687270461.005654: etypes requested in TGS request: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[124798] 1687270461.005656: Encoding request body and padata into FAST request
[124798] 1687270461.005657: Sending request (5335 bytes) to IPA.EXAMPLE.COM
[124798] 1687270461.005658: Initiating TCP connection to stream 192.168.0.5:88
[124798] 1687270461.005659: Sending TCP request to stream 192.168.0.5:88
[124798] 1687270461.005660: Received answer (508 bytes) from stream 192.168.0.5:88
[124798] 1687270461.005661: Terminating TCP connection to stream 192.168.0.5:88
[124798] 1687270461.005662: Response was from master KDC
[124798] 1687270461.005663: Decoding FAST response
[124798] 1687270461.005664: Decoding FAST response
[124798] 1687270461.005665: Got cred; -1765328371/KDC can't fulfill requested option
[124798] 1687270461.005669: Destroying ccache MEMORY:9LUdBez
The only thing that looks like an error in that output is "KDC can't
fulfill requested option".
The last place I can think of looking is in /var/log/krb5kdc.log:
Jun 20 14:17:34 ipa5.ipa.example.com krb5kdc[119948](info): TGS_REQ : handle_authdata (-1765328371)
Jun 20 14:17:34 ipa5.ipa.example.com krb5kdc[119948](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168.0.5: HANDLE_AUTHDATA: authtime 1687270653, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM for ldap/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM, KDC can't fulfill requested option
Jun 20 14:17:34 ipa5.ipa.example.com krb5kdc[119948](info): ... CONSTRAINED-DELEGATION s4u-client=host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM
Jun 20 14:17:34 ipa5.ipa.example.com krb5kdc[119948](info): closing down fd 12
There's another instance of "KDC can't fulfill requested option".
My best guess is that there's something wrong with the constrained
delegation setup that lets ipaapi access the directory on behalf of the
client host? But this looks fine:
$ ipa servicedelegationrule-show ipa-http-delegation
Delegation name: ipa-http-delegation
Allowed Target: ipa-ldap-delegation-targets, ipa-cifs-delegation-targets
Member principals: HTTP/ipa3.ipa.example.com(a)IPA.EXAMPLE.COM, HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM, HTTP/ipa6.ipa.example.com(a)IPA.EXAMPLE.COM
$ ipa servicedelegationtarget-show ipa-ldap-delegation-targets
Delegation name: ipa-ldap-delegation-targets
Member principals: ldap/ipa3.ipa.example.com(a)IPA.EXAMPLE.COM, ldap/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM, ldap/ipa6.ipa.example.com(a)IPA.EXAMPLE.COM
... and in any case a simple 'ipa cert-request' as the host worked fine,
it's only certmonger's attempts to request a certificate that are
failing.
The IPA client has:
ipa-client-4.9.11-5.module+el8.8.0+18147+84fe6ec1.x86_64
certmonger-0.79.17-2.el8.x86_64
... and the server has:
ipa-server-4.9.11-5.module+el8.8.0+18146+a1d8660b.x86_64
Any troubleshooting help is really appreciated!
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
2 months
ipa: ERROR: No valid Negotiate header - from/in container replica
by lejeczek
Hi guys.
This is my first trial/test of replicas in container - here
I added a replica to already existing, bare-metal IPA
domain, which otherwise works a okey - so numerous issues
are possible.
In container, only in this replica, I get:
bash-5.1# ipa dnszone-find
ipa: ERROR: No valid Negotiate header in server response
What that is, might be, a symptom of? Where to go with
troubleshooting?
All thoughts share are much appreciated.
many thanks, L.
3 months
Login failed due to an unknown reason
by Dan West
I am running into a strange issue with a few user accounts where logging into the web interface gives them the error message "Login failed due to an unknown reason”. It also prevents them from SSH’ing into IPA bound systems using passwords. Pubkeys work fine (as long as it is manually added to the local accounts) and any services I have bound to it (Gitlab, Mattermost, Owncloud, etc) seem to work fine. I ’think’ this is kerberos related since the only services that are using it is SSH and probably the IPA web interface. Here is the apache error log for it:
[Thu Jan 13 09:15:38.688228 2022] [wsgi:error] [pid 579266:tid 139812542121728] [remote xx.xxx.xx.xxx:52162] ipa: INFO: 401 Unauthorized: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2598844948): TGT has been revoked
I ’think’ the message "TGT has been revoked” is due to the 401 error, since the user is not showing as being authorized to login. However, this user is enabled and I have tried a number of things to try to fix it:
1. Disable/Re-enable account
2. Reset passwords
3. Kinit username (seems to get a ticket, but logins still do not work)
4. Run the account migration task (using the web gui)
5. Restart the IPA server and services
6. Re-initialize the IPA server from another master
Also, I can confirm that the passwords are correct since a failed password error message shows up differently and other services are using it correctly. Going down the Kerberos path, here is the krb5kdc log file:
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): AS_REQ (7 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25), DEPRECATED:arcfour-hmac(23)}) yy.yy.yy.yy: NEEDED_PREAUTH: WELLKNOWN/ANONYMOUS(a)EXAMPLE.COM for krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, Additional pre-authentication required
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): closing down fd 12
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): AS_REQ (7 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25), DEPRECATED:arcfour-hmac(23)}) yy.yy.yy.yy: ISSUE: authtime 1642094138, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, WELLKNOWN/ANONYMOUS(a)EXAMPLE.COM for krbtgt/EXAMPLE.COM(a)EXAMPLE.COM
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): closing down fd 12
Jan 13 09:15:38 ipa.example.com krb5kdc[579225](info): AS_REQ (7 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25), DEPRECATED:arcfour-hmac(23)}) yy.yy.yy.yy: NEEDED_PREAUTH: testuser(a)EXAMPLE.COM for krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, Additional pre-authentication required
Jan 13 09:15:38 ipa.example.com krb5kdc[579225](info): closing down fd 12
Jan 13 09:15:38 ipa.example.com krb5kdc[579225](info): AS_REQ (7 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25), DEPRECATED:arcfour-hmac(23)}) yy.yy.yy.yy: ISSUE: authtime 1642094138, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, testuser(a)EXAMPLE.COM for krbtgt/EXAMPLE.COM(a)EXAMPLE.COM
Jan 13 09:15:38 ipa.example.com krb5kdc[579225](info): closing down fd 12
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](Error): PAC issue: PAC record claims domain SID different to local domain SID or any trusted domain SID: local [S-1-5-21-997841278-3584560916-1456654135], PAC [S-1-5-21-2108153867-2082035330-3701898995]
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): TGS_REQ : handle_authdata (-1765328364)
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): TGS_REQ (7 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25), DEPRECATED:arcfour-hmac(23)}) yy.yy.yy.yy: HANDLE_AUTHDATA: authtime 1642094138, etypes {rep=UNSUPPORTED:(0)} testuser(a)EXAMPLE.COM for HTTP/ipa.example.com(a)EXAMPLE.COM, TGT has been revoked
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): closing down fd 12
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](Error): PAC issue: PAC record claims domain SID different to local domain SID or any trusted domain SID: local [S-1-5-21-997841278-3584560916-1456654135], PAC [S-1-5-21-2108153867-2082035330-3701898995]
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): TGS_REQ : handle_authdata (-1765328364)
Jan 13 09:15:38 ipa.example.com krb5kdc[579226](info): TGS_REQ (7 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25), DEPRECATED:arcfour-hmac(23)}) yy.yy.yy.yy: HANDLE_AUTHDATA: authtime 1642094138, etypes {rep=UNSUPPORTED:(0)} testuser(a)EXAMPLE.COM for HTTP/ipa.example.com(a)EXAMPLE.COM, TGT has been revoked
I only see two errors that might be related:
"PAC record claims domain SID different to local domain SID or any trusted domain SID”
"DEPRECATED:arcfour-hmac(23)”
However, those might just be red herrings or something else that is unrelated.
So far, there are only a small number of accounts that have this problem, but more seem to be popping up on a daily basis. The only fix I have found is the nuclear option, where I completely remove the account and then add it back in with the same UID/GID, group memberships and policies. After that it seems to work fine. However, I would rather not want to do this to all accounts since that would be a logistical nightmare.
Are there any suggestions for either troubleshooting or fixing this problem with a lighter approach? Is it possible to reset or regenerate the users kerberos authentication?
Thanks,
Dan West
Systems Administrator
Galois Inc.
http://galois.com
3 months, 1 week
certmonger error on ubuntu
by Robson Francisco de Souza
Hello!
I've been running FreeIPA 4.3.1 on Ubuntu 16.04 for almost two years and
most certificates should expire within three weeks. As this deadline
approaches, I noticed certmonger has been unable to renew certificates due
to the error below.
After googling for two days, I found this issue has been observed by many
people before, mostly after expiration of the certificates, as in
https://tinyurl.com/vajmocw
Still, I couldn't find a solution to this problem.
If it is impossible to fix this issue while using FreeIPA 4.3.1, I would
like to:
1) Find a way to renew all certificates even if certmonger can't be fixed.
This would allow me to postpone the solution to after the next OS and/or
FreeIPA upgrade
2) Find out what version of FreeIPA I should upgrade to while the operating
system remains Ubuntu 16.04
Any help would be appreciated!
Thanks!
Robson
======> Command: systemctl status certmonger
Nov 17 20:53:08 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
20:53:08 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875188]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875188]: dogtag-ipa-renew-agent returned 3
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:10:13 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:25:20 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875738]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:25:20 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875738]: dogtag-ipa-renew-agent returned 3
Nov 17 21:25:21 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:25:21 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875766]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875766]: dogtag-ipa-renew-agent returned 3
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:25:31 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
--
Robson Francisco de Souza, PhD
Laboratório de Estrutura e Evolução de Proteínas (LEEP/PSEL)
Departamento de Microbiologia
Instituto de Ciências Biomédicas
Universidade de São Paulo
Av. Prof. Lineu Prestes, 1374 - Ed. Biomédicas II - Sala 250 - 2o. andar
Tel: 3091-0891
Cidade Universitária - CEP 05508-900 - São Paulo - SP - Brasil
----
Robson Francisco de Souza, PhD
Protein Structure and Evolution Laboratory (LEEP/PSEL)
Microbiology Departament
Biomedical Sciences Institute
University of Sao Paulo
Av. Prof. Lineu Prestes, 1374 - Biomédicas II - Sala 250
Phone: 55-11-3091-0891
Cidade Universitária - ZIP 05508-900 - São Paulo - SP - Brazil
4 months, 1 week
Re: issues ssh'ing as AD user to freeipa client
by Sumit Bose
Am Wed, Dec 13, 2023 at 11:49:00PM +0000 schrieb Ostrom, Erik via FreeIPA-users:
> Hi,
>
> I'm having some issues ssh'ing as an AD user to a freeipa client, but I can successfully ssh as the same user to the IPA master.
> Our IPA domain, ipa.subdomain.contoso.com, is set up with a one-way trust with ad.contoso.com (IPA trusts ADs users). I have the standard "allow all" HBAC rule in place on FreeIPA for testing purposes. ad.contoso.com is a relatively huge AD, with over 400,000 user accounts.
>
> ssh erik-ipa(a)freeipa1.ipa.subdomain.contoso.com --- (IPA user to FreeIPA master), works
> ssh erik-ad@ad.contso.com(a)freeipa1.ipa.subdomain.contoso.com --- (AD user to FreeIPA master), works
> ssh erik-ipa(a)rl9-ipa-client1.in.subdomain.contoso.com --- (IPA user to FreeIPA client), works
> ssh erik-ad@ad.contoso.com(a)rl9-ipa-client1.in.subdomain.contoso.com --- (AD user to FreeIPA client), doesn't work
>
> I'm not sure what to look at in the SSSD logs to see what's going wrong here. I have uploaded sanitized SSSD logs from rl9-ipa-client1.in.subdomain.contoso.com for a failed login attempt (listed above as not working) at the following link:https://privatebin.net/?55e82c73463ae145#A59jSajU1ZwEwr3nEKhPqsT8Um4...
Hi,
according to the logs, the IPA server needs too much time to prepare the
data of the AD user which the client requested.
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_get_acct_info_send] (0x0400): [RID#229] Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust user [erik-ad] to IPA server
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x0400): [RID#229] Executing extended operation
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x2000): [RID#229] ldap_extended_operation sent, msgid = 41
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): [RID#229] New operation 41 timeout 6
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: sh[0x55e456f262f0], connected[1], ops[0x55e456efac80], ldap[0x55e455ed5310]
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
(2023-12-12 16:31:19): [be[ipa.subdomain.contoso.com]] [sdap_op_timeout] (0x1000): [RID#229] Issuing timeout [ldap_opt_timeout] for message id 41
Typically this means that the server has to refresh some or all cached
data of the user, which in this case will include all group-memberships
and for some technical reasons this means refreshing all related
expired groups and their members.
At least for the group members this can be speed up by setting
ignore_group_members = True
subdomain_inherit = ignore_group_members
in the [domain/...] section on IPA servers and clients.
Another option is to set
refresh_expired_interval = 4000
in the [domain/...] sections on the IPA servers to make sure that SSSD
will try every 4000s to refresh cached entries which are about to
expire. As a result the IPA servers should be able to always reply to
request form IPA client with cached data without the need to refresh it.
HTH
bye,
Sumit
>
> If anyone can tell what my issue is here, or if other logs would be helpful let me know. I appreciate the help!
>
> Thanks,
> Erik
> --
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
4 months, 2 weeks
Greenfield FreeIPA deployment - is it OK to put FreeIPA at the domain apex, or a "best practice" to put it in a subdomain?
by Braden McGrath
Hello FreeIPA-users. The Subject line is the core of my question here; I'll provide a bit more detail below.
I work for what is (effectively) a startup, non-profit internet provider. I have an extensive Windows background, and "know enough to be dangerous" with Linux & BSD (have been tinkering with GNU/Linux on and off since Slackware 3.0 or 3.1). I'm very familiar with Windows Active Directory, but the org does not have any AD infrastructure right now (and being nonprofit, are trying to avoid spending money for MS, especially when all of the other VMs will be Linux or BSD anyway).
Given the nonprofit nature, I discovered FreeIPA when looking for a free centralized directory system. The goal is to consolidate all credentials for *other* Linux VMs (customer-facing DNS, CRM web server, SNMP/network graphing servers, etc) as well as provide a back-end for RADIUS for management of network equipment (switches, routers, P2P wireless, etc). Simplifying DNS management and replication is also appealing, I'd rather administrate one system than two or three.
In case it changes your opinion of the plan at all - all of the network equipment and VMs will be on *private* (10.x) IPv4 space and behind one or more firewalls, at least initially. We do want to add public IPv6, but do not have that yet. We only have a small allocation (/26) of public v4 from our upstream that will be NATed through a firewall and not directly on any devices. The traffic to FreeIPA is going to be internal-only, I do not plan on exposing FreeIPA's DNS "to the world" at all. Even customer-facing internal DNS will likely be through separate caching forwarders pointing back to FreeIPA.
I have a completely unused, publicly registered domain (let's just call it "example.net" for this thread) available to dedicate to this system. We also own "example.org" and are using that for our public web presence, and I intend to keep that entirely standalone.
Given that I have no current "interoperability" concerns, is there anything "wrong" with putting FreeIPA directly at the root of example.net? Or would it be more wise, from an interop, security, or manageability standpoint (i.e. a "best practice"), to root FreeIPA at something like auth.example.net or ipa.example.net and then have a separate set of nameservers handling the base domain? If I put FreeIPA's root (and Kerberos realm) in a subdomain, is it possible to *also* have it manage the parent domain's DNS entries?
I've read through the Quick Start Guide and Deployment Recommendations (https://www.freeipa.org/page/Deployment_Recommendations), which is part of how I've come to the decisions I've made thus far. I couldn't really find guidance one way or the other on whether FreeIPA "should" be in a subdomain or not, hence this posting. I would appreciate any insight the community can provide!
5 months
