ssh key issues
by Andrew Meyer
I recently cleaned up a few server in my home lab. Deleted servers that I no longer needed. However It seems I have a server with an IP address that used previously. FreeIPA is reporting that it is in /var/lib/sss/pubconf/known_hosts but I can't reverse engineer the hostname by doing sshkey -R 1.2.3.4. I have run into this issue previously but it has bee quite some time. When I go to delete the line from /var/lib/sss/pubconf/known_hosts it is gone. If someone could help me that would be great. I didn't see anything on my FreeIPA master that indicated I did anything there.
1 year, 9 months
Could not login with AD user
by Ronald Wimmer
Today I was not able to log in with an AD user to an IPA client within a
test setup. IPA users worked fine.
DNS is managed externally. I figured out that the DNS-Record of that
particular IPA client has not been created correctly. After having
corrected the DNS entry and having dropped the SSSD cache on that client
I could login with my AD user.
Do you have an explanation for that or was it just a coincidence?
Cheers,
Ronald
1 year, 9 months
keycloak - the other way around?
by lejeczek
Hi guys.
I've only stumbled upon whole Keycloak thing thus go easy on
me please. I wonder if Keycload can be a "provider" to
freeIPA in some way?
One such a scenario where I think Keycloak might be a golden
egg - if it worked that is - is as a "middle-man" for user
base between(or from to) AD and freeIPA when full & legit
trust is not possible. Does that make sense?
many thanks, L.
1 year, 9 months
freeipa/certmonger for openvpn user certificates
by Patrick Spinler
Hi,
I'm setting up an openvpn server and I'd like to use our already existing FreeIPA CA to issue user keys/certs for openvpn's use. Since our OpenVPN box is a freeipa client, I thought it'd be nice to use certmonger to issue and keep up to date these certs.
Ergo, I've created a certificate profile:
pat@apex-freeipa ~$ ipa certprofile-show --all OpenVPNUserCert
dn: cn=OpenVPNUserCert,cn=certprofiles,cn=ca,dc=int,dc=apexmw,dc=com
Profile ID: OpenVPNUserCert
Profile description: OpenVPN User Certificates
Store issued certificates: FALSE
objectclass: ipacertprofile, top
And also a CA acl. For experimentation (and working vs our test freeipa) I've left this as wide open as I can:
[pat@apex-freeipa ~]$ ipa caacl-show --all OpenVPN_User_Certificate_ACL
dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com
ACL name: OpenVPN_User_Certificate_ACL
Enabled: TRUE
CA category: all
Profile category: all
User category: all
Host category: all
Service category: all
ipauniqueid: 6dde33a6-7849-11e9-aa05-525400b52c7b
objectclass: ipaassociation, ipacaacl
Then, on my openvpn server, I ask for a cert for use for one of my users (myself, in this case):
root@apex-openvpn:~# ipa-getcert request -f /etc/openvpn/client/pat.crt -k /etc/openvpn/client/pat.key -r -N 'CN=pat,O=INT.APEXMW.COM' -K pat -g 4096 --profile OpenVPNUserCert
New signing request "20190603014016" added.
But, it fails due to an access err vs the 'userCertificate' attribute of my account:
root@apex-openvpn:~# ipa-getcert list
(...snippy snip excess...)
Request ID '20190603014016':
status: CA_REJECTED
ca-error: Server at https://apex-freeipa.int.apexmw.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com'.).
stuck: yes
key pair storage: type=FILE,location='/etc/openvpn/client/pat.key'
certificate: type=FILE,location='/etc/openvpn/client/pat.crt'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
If I look at the dirsrv log, here's the accesses I see for this request (trimmed off the date/time to make the lines a _little_ shorter):
root@apex-freeipa slapd-INT-APEXMW-COM# grep conn=178 access | cut -d' ' -f3-
conn=178 fd=114 slot=114 connection from 10.10.200.1 to 10.10.200.1
conn=178 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO
conn=178 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0025554208 dn="fqdn=apex-openvpn.int.apexmw.com,cn=computers,cn=accounts,dc=int,dc=apexmw,dc=com"
conn=178 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL
conn=178 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0001319554
conn=178 op=2 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL
conn=178 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000979573
conn=178 op=3 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL
conn=178 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0000736730
conn=178 op=4 SRCH base="cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaca)(cn=ipa))" attrs=""
conn=178 op=4 RESULT err=0 tag=101 nentries=1 etime=0.0000499142
conn=178 op=5 SRCH base="cn=ipa,cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaCaId ipaCaSubjectDN cn ipaCaIssuerDN description"
conn=178 op=5 RESULT err=0 tag=101 nentries=1 etime=0.0000482726
conn=178 op=6 SRCH base="cn=apex-freeipa.int.apexmw.com,cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=CA))" attrs=ALL
conn=178 op=6 RESULT err=0 tag=101 nentries=1 etime=0.0000950646 notes=U
conn=178 op=7 SRCH base="cn=accounts,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=pat(a)INT.APEXMW.COM))" attrs=ALL
conn=178 op=7 RESULT err=0 tag=101 nentries=1 etime=0.0002747849
conn=178 op=8 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin"
conn=178 op=8 RESULT err=0 tag=120 nentries=0 etime=0.0000135034
conn=178 op=9 SRCH base="cn=request certificate ignore caacl,cn=virtual operations,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass"
conn=178 op=9 RESULT err=0 tag=101 nentries=1 etime=0.0000932668 - entryLevelRights: none
conn=178 op=10 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="distinguishedName"
conn=178 op=10 RESULT err=0 tag=101 nentries=1 etime=0.0000640289
conn=178 op=11 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="telephoneNumber ipaSshPubKey uid krbCanonicalName ipatokenRadiusUserName ipaUserAuthType krbPrincipalExpiration homeDirectory nsAccountLock usercertificate;binary title loginShell uidNumber mail ipaCertMapData memberOf memberofindirect krbPrincipalName givenName gidNumber sn ou userClass ipatokenRadiusConfigLink"
conn=178 op=11 RESULT err=0 tag=101 nentries=1 etime=0.0001401737
conn=178 op=12 SRCH base="dc=int,dc=apexmw,dc=com" scope=2 filter="(|(member=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com)(memberUser=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com)(memberHost=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com))" attrs=""
conn=178 op=12 RESULT err=0 tag=101 nentries=7 etime=0.0001492344 notes=P pr_idx=0 pr_cookie=-1
conn=178 op=13 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(userPassword=*)" attrs="userPassword"
conn=178 op=13 RESULT err=0 tag=101 nentries=1 etime=0.0000524838
conn=178 op=14 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey"
conn=178 op=14 RESULT err=0 tag=101 nentries=1 etime=0.0000597589
conn=178 op=15 SRCH base="ipaUniqueID=80b23b30-6a0c-11e9-baa3-525400b52c7b,cn=sudorules,cn=sudo,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="cn"
conn=178 op=15 RESULT err=0 tag=101 nentries=1 etime=0.0000379744
conn=178 op=16 SRCH base="ipaUniqueID=5fb3a640-705a-11e9-aa05-525400b52c7b,cn=hbac,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="cn"
conn=178 op=16 RESULT err=0 tag=101 nentries=1 etime=0.0000337904
conn=178 op=17 SRCH base="cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com" scope=1 filter="(&(objectClass=ipaassociation)(objectClass=ipacaacl))" attrs="serviceCategory cn ipaMemberCertProfile ipaMemberCa ipaCertProfileCategory memberUser userCategory hostCategory memberHost ipaEnabledFlag ipaCaCategory memberService description"
conn=178 op=17 RESULT err=0 tag=101 nentries=2 etime=0.0001647058
conn=178 op=18 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin"
conn=178 op=18 RESULT err=0 tag=120 nentries=0 etime=0.0000138321
conn=178 op=19 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="userCertificate"
conn=178 op=19 RESULT err=0 tag=101 nentries=1 etime=0.0001475052 - entryLevelRights: none
conn=178 op=20 UNBIND
conn=178 op=20 fd=114 closed - U1
To begin with, I note that this session does a BIND with 'dn=""', right at the beginning, it's essentially an anonymous bind, yah?
That operation near the end, here:
op=17 SRCH base="cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com" scope=1 filter="(&(objectClass=ipaassociation)(objectClass=ipacaacl))"
seems like it might be kinda key. and indeed, if I attempt to run this by hand as an anonymous bind, I get no results:
root@apex-freeipa slapd-INT-APEXMW-COM# ldapsearch -x -h localhost -b dc=int,dc=apexmw,dc=com -s sub "(|(objectClass=ipaassociation)(objectClass=ipacaacl))"
# extended LDIF
#
# LDAPv3
# base <dc=int,dc=apexmw,dc=com> with scope subtree
# filter: (|(objectClass=ipaassociation)(objectClass=ipacaacl))
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
It's only if I run this as an _authenticated_ bind, that I can find my ACL:
root@apex-freeipa slapd-INT-APEXMW-COM# ldapsearch -x -D "cn=Directory Manager" -W -h localhost -b dc=int,dc=apexmw,dc=com -s sub "(&(objectClass=ipaassociation)(objectClass=ipacaacl))" cn
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=int,dc=apexmw,dc=com> with scope subtree
# filter: (&(objectClass=ipaassociation)(objectClass=ipacaacl))
# requesting: cn
#
# c98b740c-6903-11e9-ad1b-525400b52c7b, caacls, ca, int.apexmw.com
dn: ipaUniqueID=c98b740c-6903-11e9-ad1b-525400b52c7b,cn=caacls,cn=ca,dc=int,dc
=apexmw,dc=com
cn: hosts_services_caIPAserviceCert
# 6dde33a6-7849-11e9-aa05-525400b52c7b, caacls, ca, int.apexmw.com
dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc
=apexmw,dc=com
cn: OpenVPN_User_Certificate_ACL
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
Is this (using certmonger to auto-issue signed certs/keys for my openvpn users) going to be essentially impossible to do, here? Do I need to go a more traditional route of creating a seperate keystore/certdb, issuing a CSR, and feeding that to FreeIPA to sign?
Any advice appreciated, and thanks in advance,
-- Pat
1 year, 9 months
Syncing AD to IPA users
by Ronald Wimmer
We managed to use IPA users as AIX users in our environment.
Preferrably, we would like to use users from an AD group directly what
does not seem to be possible without SSSD for AIX, right?
As an alternative it would be great to synchronize users in a specific
AD group to IPA users. I already have a draft of a python script in mind
that could do the job.
Is there any way go synchronize a user's password from AD?
Cheers,
Ronald
1 year, 10 months
Broken ipa replica
by Giulio Casella
Hi everyone,
I'm stuck with a broken replica. I had a setup with two ipa server in
replica (ipa-server-4.6.4 on CentOS 7.6), let's say "idc01" and "idc02".
Due to heavy load idc01 crashed many times, and was not working anymore.
So I tried to redo the replica again. At first I tried to
"ipa-replica-manage re-initialize", with no success.
Now I'm trying to redo from scratch the replica setup: on idc02 I
removed the segments (ipa topologysegment-del, for both ca and domain
suffix), on idc01 I removed everything (ipa-server-install --uninstall),
then I joined domain (ipa-client-install), and everything is working so far.
When doing "ipa-replica-install" on idc01 I get:
[...]
[28/41]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 22 seconds elapsed
[ldap://idc02.my.dom.ain:389] reports: Update failed! Status: [Error
(-11) connection error: Unknown connection error (-11) - Total update
aborted]
And on idc02 (the working server), in
/var/log/dirsrv/slapd-MY-DOM-AIN/errors I find lines stating:
[20/Mar/2019:09:28:06.545187923 +0100] - INFO - NSMMReplicationPlugin -
repl5_tot_run - Beginning total update of replica
"agmt="cn=meToidc01.my.dom.ain" (idc01:389)".
[20/Mar/2019:09:28:26.528046160 +0100] - ERR - NSMMReplicationPlugin -
perform_operation - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Failed
to send extended operation: LDAP error -1 (Can't contact LDAP server)
[20/Mar/2019:09:28:26.530763939 +0100] - ERR - NSMMReplicationPlugin -
repl5_tot_log_operation_failure - agmt="cn=meToidc01.my.dom.ain"
(idc01:389): Received error -1 (Can't contact LDAP server): for total
update operation
[20/Mar/2019:09:28:26.532678072 +0100] - ERR - NSMMReplicationPlugin -
release_replica - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Unable to
send endReplication extended operation (Can't contact LDAP server)
[20/Mar/2019:09:28:26.534307539 +0100] - ERR - NSMMReplicationPlugin -
repl5_tot_run - Total update failed for replica
"agmt="cn=meToidc01.my.dom.ain" (idc01:389)", error (-11)
[20/Mar/2019:09:28:26.561763168 +0100] - INFO - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meToidc01.my.dom.ain" (idc01:389):
Replication bind with GSSAPI auth resumed
[20/Mar/2019:09:28:26.582389258 +0100] - WARN - NSMMReplicationPlugin -
repl5_inc_run - agmt="cn=meToidc01.my.dom.ain" (idc01:389): The remote
replica has a different database generation ID than the local database.
You may have to reinitialize the remote replica, or the local replica.
It seems that idc02 remembers something about the old replica.
Any hint?
Thank you in advance,
Giulio
1 year, 11 months
error: PAM: User account has expired for <user>
by Ben Aveling
We're having users unable to login on some hosts.
The error message in /var/log/secure is:
sshd[29399]: error: PAM: User account has expired for <<username>> from <<ip address>>
The same users can login fine to other hosts, suggesting it's a config or other issue with these specific hosts.
Has anyone seen anything similar?
1 year, 11 months
Unable to Login to Windows Server With IPA user
by Damola Azeez
I'm Unable to login with the IPA users i created and mapped to the windows server. Whenever i attempt to login, I'm greeted with a message saying the user has no right to login because it is not in the Remote desktop group. I can confirm that the users are in the remote desktop group on windows server.
Link to the image that describes the situation
(https://www.linkpicture.com/q/Screenshot_1_257.png)
Version/Release/Distribution
=======================
ipa-server-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.x86_64
ipa-client-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.x86_64
389-ds-base-1.4.3.23-14.module+el8.5.0+20517+748852bc.x86_64
pki-ca-10.11.2-4.0.1.module+el8.5.0+20486+8c04dafa.noarch
krb5-server-1.18.2-14.el8.x86_64
1 year, 11 months
Trouble with IPA tools
by Victoria Fierce
Howdy.
I've been a long-time user of freeipa and have had a small instance running at home via fedora packages for the past 5 years or so. Its actually hard to know just how long I've had it running, but that's besides the point; for what feels like ages I've never had to really mess with it and it kept on ticking. Until recently.
I'm no longer able to use the ipa command line tool or the webui. The webui correctly rejects any invalid passwords with an invalid password message, but any /correct/ credentials simply says "Your session has expired. Please log in again.". All of my clients are using the same NTP server as the server, nothing it out of sync, and caches have been cleared multiple times. I know this isn't a browser issue, because of the next point:
I can't use the ipa command on my server anymore. Here's a brief sample of one such attempt:
[root@io kdc]# kinit admin
Password for admin(a)MALLOC.HACKERBOTS.NET:
[root@io kdc]# ipa -d
ipa: DEBUG: Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa: DEBUG: Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
ipa: DEBUG: Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin(a)MALLOC.HACKERBOTS.NET'
ipa: DEBUG: trying https://io.malloc.hackerbots.net/ipa/json
ipa: DEBUG: Created connection context.rpcclient_139701656917472
ipa: DEBUG: [try 1]: Forwarding 'schema' to json server 'https://io.malloc.hackerbots.net/ipa/json'
ipa: DEBUG: New HTTP connection (io.malloc.hackerbots.net)
ipa: DEBUG: received Set-Cookie (<class 'list'>)'['ipa_session=MagBearerToken=lflo9aPGmula4dSW7i8LbiI7ZNH%2bSycMGOGpqZiZkD0bydWnWfzv7bSuTIzsvdQGPas3BatwwBmREuVlVM0iT0%2by2tto74XdZXXYrv4MhOFT7q3vECladuGsQgqInfrIeLG4a8LMQ0CqE8exLdtttJtt%2fydt1lHzsbHCTigV7TS8CF%2bnZ7558549uo5rJtG%2f6YXG7p0zzhQ4hUYOPwjR%2byux%2bIQhK5PeVu3TKnofFZk%3d;path=/ipa;httponly;secure;']'
ipa: DEBUG: storing cookie 'ipa_session=MagBearerToken=lflo9aPGmula4dSW7i8LbiI7ZNH%2bSycMGOGpqZiZkD0bydWnWfzv7bSuTIzsvdQGPas3BatwwBmREuVlVM0iT0%2by2tto74XdZXXYrv4MhOFT7q3vECladuGsQgqInfrIeLG4a8LMQ0CqE8exLdtttJtt%2fydt1lHzsbHCTigV7TS8CF%2bnZ7558549uo5rJtG%2f6YXG7p0zzhQ4hUYOPwjR%2byux%2bIQhK5PeVu3TKnofFZk%3d;' for principal admin(a)MALLOC.HACKERBOTS.NET
ipa: DEBUG: Destroyed connection context.rpcclient_139701656917472
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
Wish I could say how long its been like this or what I did to break it, but again, its been running for so long that I've never really had to check in on it! This is a Fedora 32 server that has gone through several distro upgrades over the years and through each one, freeipa kept running without issue. I'm certain that at some point in the last year I've upgraded a package that broke this, but there is no way to check. Kerberos continues to work fine; I can login to other services and change passwords and whatnot. ldapsearch returns results and I can bind to it, and other services that utilize ldap for authentication still work great. Except for, of course, the freeipa web app. It looks like freeipa hasn't seen a new release in quite some time, so I'm prepared to do a bunch of debugging myself if anyone could point me in the right directions.
Additionally, here's the apache error_log with debug=true in /etc/ipa/server.conf:
[Mon Apr 18 10:57:31.776194 2022] [ssl:info] [pid 1989623:tid 1989819] [client 127.0.0.1:42826] AH01964: Connection to child 8 established (server io.malloc.hackerbots.net:443)
[Mon Apr 18 10:57:31.776376 2022] [ssl:debug] [pid 1989623:tid 1989819] ssl_engine_kernel.c(2374): [client 127.0.0.1:42826] AH02043: SSL virtual host for servername io.malloc.hackerbots.net found
[Mon Apr 18 10:57:31.779851 2022] [ssl:debug] [pid 1989623:tid 1989819] ssl_engine_kernel.c(2254): [client 127.0.0.1:42826] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits)
[Mon Apr 18 10:57:31.779966 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(493): AH00831: socache_shmcb_store (0x4a -> subcache 10)
[Mon Apr 18 10:57:31.779974 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(847): AH00847: insert happened at idx=2, data=(378:410)
[Mon Apr 18 10:57:31.779977 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(850): AH00848: finished insert, subcache: idx_pos/idx_used=0/3, data_pos/data_used=0/595
[Mon Apr 18 10:57:31.779981 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(515): AH00834: leaving socache_shmcb_store successfully
[Mon Apr 18 10:57:31.780083 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(493): AH00831: socache_shmcb_store (0xde -> subcache 30)
[Mon Apr 18 10:57:31.780088 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(847): AH00847: insert happened at idx=1, data=(217:249)
[Mon Apr 18 10:57:31.780091 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(850): AH00848: finished insert, subcache: idx_pos/idx_used=0/2, data_pos/data_used=0/434
[Mon Apr 18 10:57:31.780094 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(515): AH00834: leaving socache_shmcb_store successfully
[Mon Apr 18 10:57:31.780181 2022] [ssl:debug] [pid 1989623:tid 1989819] ssl_engine_kernel.c(415): [client 127.0.0.1:42826] AH02034: Initial (No.1) HTTPS request received for child 8 (server io.malloc.hackerbots.net:443), referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780373 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780384 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780395 2022] [auth_gssapi:debug] [pid 1989623:tid 1989819] mod_auth_gssapi.c(893): [client 127.0.0.1:42826] URI: /ipa/session/json, no main, no prev, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780450 2022] [auth_gssapi:debug] [pid 1989623:tid 1989819] mod_auth_gssapi.c(983): [client 127.0.0.1:42826] Already established context found!, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780482 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of Require valid-user : granted, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780486 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of <RequireAny>: granted, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780544 2022] [lookup_identity:debug] [pid 1989623:tid 1989819] mod_lookup_identity.c(445): [client 127.0.0.1:42826] invoked for user admin(a)MALLOC.HACKERBOTS.NET, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780635 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of Require all granted: granted, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780641 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of <RequireAny>: granted, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780648 2022] [auth_gssapi:debug] [pid 1989623:tid 1989819] mod_auth_gssapi.c(726): [client 127.0.0.1:42826] GSSapiImpersonate not On, skipping impersonation., referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.781246 2022] [wsgi:error] [pid 1989622:tid 1989934] [remote 127.0.0.1:42826] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Mon Apr 18 10:57:31.781331 2022] [wsgi:error] [pid 1989622:tid 1989934] [remote 127.0.0.1:42826] ipa: DEBUG: WSGI jsonserver_session.__call__:
[Mon Apr 18 10:57:31.836341 2022] [wsgi:error] [pid 1989622:tid 1989934] [remote 127.0.0.1:42826] ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
1 year, 11 months
Migrating IPA CA to new hosts
by Adam Bishop
We're in the process of decomissioning our oldest IPA servers (built in 2014). We've migrated the roles successfully and are making sure everything is ready to switch over to the new set, and just wanted to check a few observations/inconsistencies.
* On some of our newer clients /etc/ipa/ca.crt contains the root and the server certificate of the enrolment server instead of just the root - did the behaviour of ipa-client-install change at some point?
* Our root contains the OCSP URI of one of the servers to be decomissioned in the Authority Information Access field. My understanding is that a client would never do an OCSP lookup on a root certificate so do we need to re-sign or add a CNAME prior to switching off?
* When enroling a client, ipa-client-install pulls down an expired RA certificate - however /var/lib/ipa/ra-agent.pem on all servers is current. Where might the expired cert be stored? Doesn't appear to cause an issue in any case.
Adam
1 year, 11 months
