IPA and legacy systems
by Ronald Wimmer
What would be a good solution to add systems where the FQDN cannot be
changed?
Would it make sense to add a second DNS A Record in the IPA domain for
each of these systems?
Is there any experience on how to deal with such a situation?
Thanks a lot in advance!
Cheers,
Ronald
2 years, 1 month
Vault: Cannot authenticate agent with certificate
by Peter Oliver
I have a CentOS 7 server running ipa-server-4.5.4, recently installed. I find that operations related to the vault feature fail. For example:
> ipa -v vault-add test --type=standard
ipa: INFO: trying https://ipa-01.example.com/ipa/session/json
ipa: INFO: [try 1]: Forwarding 'vault_add_internal/1' to json server 'https://ipa-01.example.com/ipa/session/json'
ipa: INFO: [try 1]: Forwarding 'vault_show/1' to json server 'https://ipa-01.example.com/ipa/session/json'
ipa: INFO: [try 1]: Forwarding 'vaultconfig_show/1' to json server 'https://ipa-01.example.com/ipa/session/json'
ipa: INFO: [try 1]: Forwarding 'vault_archive_internal/1' to json server 'https://ipa-01.example.com/ipa/session/json'
ipa: ERROR: an internal error has occurred
In /var/log/pki/pki-tomcat/kra/system I see the following message:
0.ajp-bio-127.0.0.1-8009-exec-15 - [02/Nov/2018:14:54:37 GMT] [6] [3] Cannot authenticate agent with certificate Serial 0x7 Subject DN CN=IPA RA,O=IPA.EXAMPLE.COM. Error: User not found
In /var/log/pki/pki-tomcat/kra/debug is see the following messages:
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: SessionContextInterceptor: SystemCertResource.getTransportCert()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: SessionContextInterceptor: Not authenticated.
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: AuthMethodInterceptor: SystemCertResource.getTransportCert()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: AuthMethodInterceptor: mapping: default
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: AuthMethodInterceptor: required auth methods: [*]
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: AuthMethodInterceptor: anonymous access allowed
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: ACLInterceptor: SystemCertResource.getTransportCert()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: ACLInterceptor.filter: no authorization required
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: ACLInterceptor: No ACL mapping; authz not required.
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: SignedAuditLogger: event AUTHZ
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: SystemCertResource.getTransportCert()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: content-type: application/json
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: accept: [application/json]
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: request format: application/json
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: response format: application/json
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: PKIRealm: Authenticating certificate chain:
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: PKIRealm.getAuditUserfromCert: certUID=CN=IPA RA, O=IPA.EXAMPLE.COM
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: PKIRealm: CN=IPA RA, O=IPA.EXAMPLE.COM
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: started
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: Retrieving client certificate
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: Got client certificate
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: Authentication: client certificate found
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 2
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 3
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuthentication: cannot map certificate to any userUser not found
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: event AUTH
Any suggestions? Has something gone wrong with the setup?
--
Peter Oliver
2 years, 9 months
Can login with non-existing user
by Ronald Wimmer
I have managed to login to an IPA client with a non-existing user.
My AD user is z123456(a)addomain.mydomain.at and I have created a similar
user called i123456(a)ipadomain.mydomain.at. What happened now is that I
could log in with the i-User and what I get to see after logging in is this:
[i123456@addomain.mydomain.at(a)as12314 ~]$ id
uid=1246600007(i123456(a)addomain.mydomain.at)
gid=1246600007(i123456(a)addomain.mydomain.at)
groups=1246600007(i123456@addomain.mydomain.at),1246600016(my-ad-group(a)ipadomain.mydomain.at)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[i123456@addomain.mydomain.at(a)as12314 ~]$ whoami
i123456(a)addomain.mydomain.at
The user i123456(a)addomain.mydomain.at does NOT exist.
addomain is set as default domain in the client's sssd.conf.
What is wrong here? Are things just displayed wrong or could it be more?
Which files do you need in order to analyze this issue?
Cheers,
Ronald
2 years, 10 months
FreeIPA v4.5.0 install lost topology suffixes
by Gavin Williams
Afternoon all
I’ve got a slightly strange one with one of our FreeIPA clusters, whereby the topology suffixes appear to have disappeared.
From what I can see, this is causing replication issues between the hosts, which is causing us issues with bootstrapping new clients against FreeIPA.
I’m not aware of any config changes that have happened on the FreeIPA hosts that could have caused this issue, so am a bit stumped atm.
Is someone able to advise next steps on how to investigate the cause and correct the configuration?
Regards
Gavin
2 years, 10 months
Automounting homeshares partially stopped working
by Ronald Wimmer
Some days ago a strange problem struck us. When colleagues access a
server using an ipa-automounted share from a Windows client they can
logon to such a server using a Kerberos ticket but they cannot access
their NFS-automounted home-share anymore. When they log on with
username/password they can.
When I try the same from my linux client I do not encounter any problems
(using the same users as in the above scenario).
Where should I start digging in order to find out what is going wrong?
Cheers,
Ronald
2 years, 10 months
Create kerberos keytab
by Boyd Ako
So, I tried doing the test section in the V4 doc below. However, I get an error.
https://www.freeipa.org/page/V4/Keytab_Retrieval
=====================
[root@ipa home]# ipa-getkeytab -r -s ipa.neverland.ddns.me -p NFS/abyss.neverland.ddns.me -k abyss-nfs.keytab
Failed to parse result: Insufficient access rights
Failed to get keytab
2 years, 10 months
Removing first freeipa master
by Jo Domsic
Hi to the good people of FreeIPA!
I'm in the process of removing old servers from my datacentar, and I was wondering if I can delete/remove (first created) freeipa server?
I have 4 masters:
[root@server] ipa-replica-manage list
freeipa03.lan: master
freeipa04.lan: master
freeipa01.lan: master <--- I want to delete this one
freeipa02.lan: master
What will happen to servers that have:
[root@server2] cat /etc/ipa/default.conf
#File modified by ipa-client-install
[global]
basedn = dc=lan
realm = LAN
domain = lan
server = freeipa01.lan
host = server2.lan
xmlrpc_uri = https://freeipa01.lan/ipa/xml
enable_ra = True
2 years, 11 months
IPA with multiple legs: hostname resolution
by Dmitry Perets
Hi,
I'd like to ask for your advise for the following topology...
On a given site, IPA server has two legs (two NICs), let's call them "inside NIC" and "outside NIC".
The inside NIC subnet is local to the site. The outside NIC subnet is interconnecting sites.
All the local clients talk to IPA via the inside NIC. But to setup a replica on another site, we must reach IPA via outside NIC (the inside subnet is not routable beyond the local site boundaries).
So the question arises: how to configure proper DNS resolution for the hostname of the IPA server itself?
DNS is handled by IPA itself, fully in our control.
So we have two options:
1. We create two A records for the same IPA hostname, let's say "ipa.site1.example.com". But then not sure if it will work fine... Technically, two IPs for the same name means load-balancing, right? So will I have intermittent connectivity issues, because it will return inside and outside IP interchangebly?
2. We create a new DNS name, e.g. "ipa-outside-site1.example.com", for the outside IP, and manually add it to the @ entry of "example.com", so that wannabe-replica on the remote site can use that FQDN as its master IPA. Will this work fine..? Will it not cause issues to the local clients on site1, who must keep using IPA with inside IP? Will it not cause issues on IPA server itself for some reason?
Please share your experience on this!
Thanks.
2 years, 11 months
CA subsystem certificates failing to renew.
by Guillermo Fuentes
Hi list,
I'm having an issue where the CA subsystem certificates are failing to renew.
*** Environment:
4 FreeIPA replica servers with CA.
Currently CentOS 7 up-to-date.
Initially setup as FreeIPA 3 on CentOS 6 upgraded to CentOS 7 and kept
up-to-date with the latest stable release available:
ipa-server-4.6.4-10.el7.centos.3.x86_64
389-ds-base-1.3.8.4-23.el7_6.x86_64
pki-ca-10.5.9-13.el7_6.noarch
pki-server-10.5.9-13.el7_6.noarch
This past June third-party wildcard certificate was installed for both
the HTTPS and LDAP servers using the ipa-server-certinstall command.
Trying to be proactive as the following CA subsystem certificates will
expire on August 12, 2019:
subject: CN=CA Audit,O=EXAMPLE.COM
subject: CN=OCSP Subsystem,O=EXAMPLE.COM
subject: CN=CA Subsystem,O=EXAMPLE.COM
subject: CN=IPA RA,O=EXAMPLE.COM
*** Issue:
Getting the following error when listing the certificate info for each
of them in the CA Renewal and CRL Master:
status: MONITORING
ca-error: Server at
"https://ipa1.example.com:8443/ca/agent/ca/profileProcess" replied: 1:
Server Internal Error
stuck: no
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=EXAMPLE.COM
expires: 2019-08-12 ...
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Getting the following error in the other CA replicas for the same
certificates (I'm assuming fixing it in the Master should take care of
the replicas):
ca-error: Invalid cookie: u''
Looking at the logs in the Master, the renewal seems to fail with an
LDAP error code 68 (Entry Already Exists) when adding serial 268304406
(when resubmitting it). Doesn't that serial suppose to exist as it's
being renewed?
These are some relevant logs after resubmitting:
- certmonger journal shows:
...
Jul 22 20:30:19 ipa1.example.com dogtag-ipa-renew-agent-submit[10116]:
GET https://ipa1.example.com:8443/ca/agent/ca/profileProcess?requestId=998004...
Jul 22 20:30:19 ipa1.example.com
dogtag-ipa-ca-renew-agent-submit[10097]: dogtag-ipa-renew-agent
returned 2
Jul 22 20:30:19 ipa1.example.com certmonger[1288]: 2019-07-22 20:30:19
[1288] Server at
"https://ipa1.example.com:8443/ca/agent/ca/profileProcess" replied: 1:
Server Internal Error
- /var/log/pki/pki-tomcat/ca/debug
...
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: Repository: checkRange
mLastSerialNo=268304406
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: Repository:
getNextSerialNumber: returning retSerial 268304406
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: CAService:
issueX509Cert: setting issuerDN using exact CA signing cert subjectDN
encoding
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: About to ca.sign cert.
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: sign cert get algorithm
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: sign cert encoding cert
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: sign cert encoding algorithm
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: CA cert signing: signing cert
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: Getting algorithm
context for SHA256withRSA RSASignatureWithSHA256Digest
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: Signing Certificate
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: storeX509Cert 268304406
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: In storeX509Cert
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: In
LdapBoundConnFactory::getConn()
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: masterConn is connected: true
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: getConn: conn is connected true
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: getConn: mNumConns now 5
[22/Jul/2019:20:30:19][http-bio-8443-exec-16]: returnConn: mNumConns now 6
LDAP operation failure - cn=268304406,ou=certificateRepository, ou=ca,
o=ipaca: error result
at com.netscape.cmscore.dbs.DBSSession.add(DBSSession.java:125)
at com.netscape.cmscore.dbs.CertificateRepository.addCertificateRecord(CertificateRepository.java:737)
at com.netscape.ca.CAService.storeX509Cert(CAService.java:893)
at com.netscape.ca.CAService.storeX509Cert(CAService.java:579)
at com.netscape.ca.CAService.issueX509Cert(CAService.java:564)
at com.netscape.cms.profile.common.CAEnrollProfile.execute(CAEnrollProfile.java:203)
at com.netscape.cms.servlet.cert.RequestProcessor.approveRequest(RequestProcessor.java:371)
at com.netscape.cms.servlet.cert.RequestProcessor.processRequest(RequestProcessor.java:173)
...
- /var/log/dirsrv/slapd-EXAMPLE-COM/access
...
[22/Jul/2019:20:30:18.703610909 +0000] conn=15 op=44 SRCH
base="cn=Certificate Manager Agents,ou=groups,o=ipaca" scope=0
filter="(uniqueMember=uid=ipara,ou=people,o=ipaca)" attrs="cn"
[22/Jul/2019:20:30:18.703958648 +0000] conn=15 op=44 RESULT err=0
tag=101 nentries=1 etime=0.0002262912
[22/Jul/2019:20:30:18.706322783 +0000] conn=14 op=2439 SRCH
base="cn=9980043,ou=ca,ou=requests,o=ipaca" scope=0
filter="(objectClass=*)" attrs=ALL
[22/Jul/2019:20:30:18.706916435 +0000] conn=14 op=2439 RESULT err=0
tag=101 nentries=1 etime=0.0020648732
[22/Jul/2019:20:30:18.758736256 +0000] conn=14 op=2440 SRCH
base="cn=9980043,ou=ca,ou=requests,o=ipaca" scope=0
filter="(objectClass=*)" attrs=ALL
[22/Jul/2019:20:30:18.759537249 +0000] conn=14 op=2440 RESULT err=0
tag=101 nentries=1 etime=0.0051791092
[22/Jul/2019:20:30:18.984013755 +0000] conn=15 op=45 SRCH
base="ou=People,o=ipaca" scope=2
filter="(description=2;268304403;CN=Certificate
Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM)" attrs=ALL
[22/Jul/2019:20:30:18.984630800 +0000] conn=15 op=45 RESULT err=0
tag=101 nentries=1 etime=0.1719630345
[22/Jul/2019:20:30:18.988077577 +0000] conn=15 op=46 SRCH
base="ou=Groups,o=ipaca" scope=2
filter="(&(objectClass=groupofuniquenames)(cn=*))" attrs=ALL
[22/Jul/2019:20:30:18.990404518 +0000] conn=15 op=46 RESULT err=0
tag=101 nentries=14 etime=0.0005432147
[22/Jul/2019:20:30:18.994230483 +0000] conn=15 op=47 SRCH
base="uid=ipara,ou=People,o=ipaca" scope=0 filter="(objectClass=*)"
attrs=ALL
[22/Jul/2019:20:30:18.994648102 +0000] conn=15 op=47 RESULT err=0
tag=101 nentries=1 etime=0.0004001393
[22/Jul/2019:20:30:18.996091715 +0000] conn=15 op=48 SRCH
base="cn=Certificate Manager Agents,ou=groups,o=ipaca" scope=0
filter="(uniqueMember=uid=ipara,ou=people,o=ipaca)" attrs="cn"
[22/Jul/2019:20:30:18.996470330 +0000] conn=15 op=48 RESULT err=0
tag=101 nentries=1 etime=0.0001510753
[22/Jul/2019:20:30:19.023676890 +0000] conn=14 op=2441 ADD
dn="cn=268304406,ou=certificateRepository,ou=ca,o=ipaca"
[22/Jul/2019:20:30:19.024455023 +0000] conn=14 op=2441 RESULT err=68
tag=105 nentries=0 etime=0.1736683576
[22/Jul/2019:20:30:19.037339256 +0000] conn=28692 op=5 UNBIND
[22/Jul/2019:20:30:19.037387249 +0000] conn=28692 op=5 fd=162 closed - U1
...
Can someone shed some light on what the problem could be and what to
try to fix it?
Any help is really appreciated.
Guillermo
2 years, 11 months