IPA CA allow CSR SAN names in external domains
by Steve Dainard
Hello
I have a RHEL7 IPA server installed as a subordinate CA. I'd like to be
able to add SAN's for a different dns domain than exists in the IPA realm.
The dns for 'otherdomain.com' is handled by active directory which my IPA
server has a cross-forest trust with.
ie:
host: client1.ipadomain.com
certificate: CN = client1.ipadomain.com, SAN = client1.ipadomain.com,
servicename.otherdomain.com
When I try to submit this CSR with 'ipa-getcert request' the IPA server
denies with: "The service principal for subject alt name
servicename.otherdomain.com in certificate request does not exist"
It seems that the default CAACL enforces a profile named
'caIPAserviceCert', but I'm having some trouble determining what can be
modified (or cloned and changed in a new profile) that would allow the CA
to sign a CSR that contains *.ipadomain.com and *.otherdomain.com in the
SAN.
This is the only section in the profile that contains SAN:
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl
policyset.serverCertSet.12.default.name=Copy Common Name to Subject
Alternative Name
Thanks,
Steve
1 year
ipa-getkeytab: PrincipalName not found
by Harald Dunkel
Hi folks,
maybe I missed something, but shouldn't admin have sufficient
privileges to run
# ipa-client-install --hostname stretch1.vs.example.de --no-ssh --no-sshd --no-nisdomain --no-sudo --no-ntp --no-dns-sshfp
# reboot
:
:
# kinit admin
# ipa-getkeytab -s ipa1.example.de -p HTTP/stretch1.vs.example.de -k /etc/apache2/apache2.keytab
?
ipa-getkeytab failed with
Failed to parse result: PrincipalName not found.
I would have expected it to create the principal on the fly.
"admin" was created at freeipa install time on the first server,
AFAIR. It is member of the "admins" and "trust admins" groups.
I am concerned that I corrupted something. Every helpful comment
is highly appreciated.
Harri
3 years, 11 months
nfsidmap/nss_getpwnam fails to resolve users with IPA/NFSv4+krb5
by Robert Sturrock
Hi All.
We have IPA setup in an AD trust to support our Linux fleet. I’m running into a problem trying to get Ubuntu (16.04) clients to resolve names/ids on an NFS-mounted filesystem from an NFS server using NFSv4/krb5. Files and directories show up as ‘nobody’ or an incorrect numerical ID when listed with ‘ls’. RHEL7 clients seem to working fine with a very similar configuration (as far as I can tell).
The particulars are:
- AD forest has domains ‘localdomain’ and ‘student.localdomain’ (my user identity is ‘user@localdomain’)
- IPA domain is ‘ipa.localdomain’
- The NFS server (RHEL7) and clients (Ubu16.04, RHEL7) are both enrolled to IPA (with 'Domain=ipa.localdomain’ in /etc/idmapd.conf).
I have mounted the NFS volume on the clients with a simple:
mount -t nfs4 nfs-server.ipa.localdomain:/export /mnt
Listing my directory as myself (‘rns@localdomain’) on the Ubuntu client, I see:
$ ls -ld rns
drwx------ 18 nobody 4294967294 4096 Oct 25 15:18 rns
.. with these corresponding nfsidmap messages:
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: key: 0x2c254c26 type: uid value: rns@localdomain(a)ipa.localdomain timeout 600
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nfs4_name_to_uid: calling nsswitch->name_to_uid
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nss_getpwnam: name 'rns@localdomain(a)ipa.localdomain' domain 'ipa.localdomain': resulting localname '(null)'
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nss_getpwnam: name 'rns@localdomain(a)ipa.localdomain' does not map into domain 'ipa.localdomain'
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22
Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nfs4_name_to_uid: final return value is -22
.. whereas on the RHEL7 client, I see:
$ ls -ld rns
drwx------. 18 rns@localdomain rns@localdomain 4096 Oct 25 15:18 rns
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: key: 0xf113fd2 type: uid value: rns@localdomain(a)ipa.localdomain timeout 600
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nfs4_name_to_uid: calling nsswitch->name_to_uid
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nss_getpwnam: name 'rns@localdomain(a)ipa.localdomain' domain 'ipa.localdomain': resulting localname 'rns@localdomain'
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nfs4_name_to_uid: final return value is 0
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: key: 0x2125a5d2 type: gid value: rns@localdomain(a)ipa.localdomain timeout 600
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: nfs4_name_to_gid: calling nsswitch->name_to_gid
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: nfs4_name_to_gid: final return value is 0
Why does the Ubuntu client's nfsidmap think that my identity doesn’t map into ‘ipa.localdomain’ and therefore (presumably) returns the error code ‘-22’?
(My identity resolves ok from the shell, using ‘id rns@localdomain’ and I can login and use local filesystems without issue).
The idmapd.conf looks like this:
[General]
Verbosity = 4
Pipefs-Directory = /run/rpc_pipefs
Domain = ipa.localdomain
Local-Realms = LOCALDOMAIN, STUDENT.LOCALDOMAIN, IPA.LOCALDOMAIN
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
[Translation]
Method = nsswitch
Any pointers appreciated!
Regards,
Robert.
4 years
IPA server upgrade fails with KDC error
by Johannes Brandstetter
Hi,
I'm trying to upgrade FreeIPA through ipa-server-upgrade from 4.4 to 4.5. The command fails with an "ACIError: Insufficient access:" . I find in the kdc log that it complains about " Database module does not match KDC version - while initializing database for realm..."
Does anybody know how to fix this?
Some more info:
$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
$ tail /var/log/krb5kdc.log
krb5kdc: Server error - while fetching master key K/M for realm XXX
krb5kdc: Database module does not match KDC version - while initializing database for realm XXX
$ sudo less /var/log/ipaupgrade.log
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG duration: 0 seconds
2017-10-16T13:04:13Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2017-10-16T13:04:14Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 46, in run
server.upgrade()
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1896, in upgrade
data_upgrade.create_instance()
File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 124, in create_instance
runtime=90)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 504, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 494, in run_step
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 96, in __start
api.Backend.ldap2.connect()
File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect
conn = self.create_connection(*args, **kw)
File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 190, in create_connection
client_controls=clientctrls)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1111, in external_bind
'', auth_tokens, server_controls, client_controls)
File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
self.gen.throw(type, value, traceback)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1007, in error_handler
raise errors.ACIError(info=info)
2017-10-16T13:04:14Z DEBUG The ipa-server-upgrade command failed, exception: ACIError: Insufficient access:
2017-10-16T13:04:14Z ERROR Insufficient access:
2017-10-16T13:04:14Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information
$ sudo less /var/log/yum.log
Oct 16 05:36:02 Updated: ipa-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:02 Updated: ipa-client-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:25 Updated: libipa_hbac-1.15.2-50.el7_4.2.x86_64
Oct 16 05:36:53 Updated: python-libipa_hbac-1.15.2-50.el7_4.2.x86_64
Oct 16 05:36:55 Updated: python2-ipalib-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:55 Updated: python2-ipaclient-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:37:23 Updated: ipa-python-compat-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:43 Updated: ipa-server-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:44 Updated: python2-ipaserver-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:44 Updated: sssd-ipa-1.15.2-50.el7_4.2.x86_64
Oct 16 05:39:01 Installed: ipa-client-4.5.0-21.el7.centos.1.2.x86_64
Oct 16 05:39:28 Updated: ipsilon-tools-ipa-2.0.2-5.el7.centos.noarch
Oct 16 05:39:29 Updated: ipa-server-4.5.0-21.el7.centos.1.2.x86_64
Oct 16 05:40:48 Erased: ipa-admintools-4.4.0-14.el7.centos.7.noarch
Oct 16 05:19:30 Updated: krb5-libs-1.15.1-8.el7.x86_64
Oct 16 05:19:30 Updated: krb5-workstation-1.15.1-8.el7.x86_64
Oct 16 05:19:31 Updated: krb5-server-1.15.1-8.el7.x86_64
Oct 16 05:19:31 Updated: krb5-pkinit-1.15.1-8.el7.x86_64
Oct 16 05:38:22 Updated: sssd-krb5-common-1.15.2-50.el7_4.2.x86_64
Oct 16 05:38:57 Updated: sssd-krb5-1.15.2-50.el7_4.2.x86_64
Cheers,
Johannes
4 years, 4 months
using freeipa with an AWS elastic load balancer
by ridha.zorgui＠infor.com
I set up a FreeIPA master and replica behind an elastic load balancer in AWS cloud. FreeIPA Clients will be contacting the replica and the master sever through the load balancer so the dns name used when configurting the clients is the ELB CNAME. The problem is when retreiving ldap data and during the authentication, the SSL handshake fails as the certificate sent back from the master or replica has a hostname different than the one used in the sssd ( the ELB CNAME). so the connection is terminated. There is a workaround which is the use reqcert=allow but this bring a security issue with a MITM attack. another solution i found is the use SAN. I was able to add the ELB DNS as a SAN in freeipa servers certificate. i made sure it is there by downloading the certificate and checking that the elb san exist but when testing it the same problem remain. Please help.
4 years, 5 months
Certificates renewing with the wrong Subject
by Roderick Johnstone
Hi
Our freeipa certificates need to be renewed due to passing their expiry
dates.
While some certificates have renewed ok, the ipaCert and
auditSigningCert are renewing but the new certificates have the wrong
Subject.
Environment is:
serverA (CRL, first, master) RHEL 7.3, ipa 4.4
serverB (replica) RHEL 7.3, ipa 4.4
serverC (replica) RHEL 7.4, ipa 4.5
Once there are renewed certificates with the wrong Subject present,
there are various problems with renewing the remaining certificates,
which I think might be related to the bad Subject:
1) When just ipaCert has the wrong subject no further renewals happen
2) When auditSigningCert has the wrong subject the ipa pki-tomcatd
service will not start and no further renewals happen.
I've been round the following loop many times on ServerA, our first master:
1) Restore good certificates from backup
2) Put the clock back to a time when certificates are all valid
3) Resubmit certificates for renewal
Each time the ipaCert renews it has the same wrong Subject. The wrong
Subject includes the host name of one of our ipa client systems.
Each time the auditSigningCert renews it has the same wrong Subject but
a different subject to the ipaCert. The wrong Subject in this case
includes the host name of a system which has never been an ipa client,
but might have been added and removed with ipa host-add and ipa host-del
for testing something, a while ago.
As far as I can see, the "cert_subject" is set correctly in the file
/var/lib/certmonger/<request id> until the point at which the
certificate is actually renewed.
I'd be very grateful for some pointers as to which configuration options
and logs to check through to resolve this problem on our production system.
If its of any relevance we did change which server is the first master
some time ago.
Thanks
Roderick Johnstone
4 years, 7 months
ipa-client-install - error - Failed to obtain host TGT: Major (851968)
by lejeczek
hi everyone
I'm trying a client, when I do:
$ ipa-client-install --no-ntp --force-join
Discovery was successful!
...
Also note that following ports are necessary for ipa-client
working properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Failed to obtain host TGT: Major (851968): Unspecified GSS
failure. Minor code may provide more information, Minor
(2529638936): Preauthentication failed
Installation failed. Rolling back changes.
-- end
At server's end(one single server in domain):
..
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560685](info): closing down fd 11
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 23
25 26}) 10.5.6.17: NEEDED_PREAUTH:
host/dzien.priv.xx.xx.priv.xx.xx.x(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
for
krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x,
Additional pre-authentication required
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): closing down fd 11
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): preauth (encrypted_timestamp) verify
failure: Preauthentication failed
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 23
25 26}) 10.5.6.17: PREAUTH_FAILED:
host/dzien.priv.xx.xx.priv.xx.xx.x(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
for
krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x,
Preauthentication failed
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560681](info): AS_REQ (8 etypes {18 17 20 19 16 23
25 26}) 10.5.6.17: NEEDED_PREAUTH:
admin(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x for
krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x,
Additional pre-authentication required
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560681](info): closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 23
25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes
{rep=18 tkt=18 ses=18}, admin(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
for
krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): TGS_REQ (8 etypes {18 17 20 19 16 23
25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes
{rep=18 tkt=18 ses=18}, admin(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
for
ldap/swir.priv.xx.xx.priv.xx.xx.x(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x
krb5kdc[1560686](info): TGS_REQ (8 etypes {18 17 20 19 16 23
25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes
{rep=18 tkt=18 ses=18}, admin(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
for
HTTP/swir.priv.xx.xx.priv.xx.xx.x(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
-- end
But after many tries(randomly) suddenly it would succeed.
Client said to use --force-join.
VERSION: 4.5.0, API_VERSION: 2.228
What can a problem?
regards, L.
4 years, 11 months
FreeIPA PKI with OpenVPN
by Mike Kelly
Hi,
I'm looking to use FreeIPA's PKI for OpenVPN... any pointers on the right
way to generate per-user certificates? (Looking to generate certs for
Android and Chrome OS, so I don't have an easy way to build a CSR on those
devices directly that I can find; I assume I want to just generate the cert
& key on the IPA server, copy it securely, then nuke the private key, and
place the public key somewhere for OpenVPN to find?
--
Mike Kelly
5 years
New replica (4.5) issues
by john.bowman＠zayo.com
After some trial and error I was finally able to get a new replica + CA (RHEL7.4 and ipa-server 4.5) added to our existing mixed (RHEL 6 and ipa server 3.0 - 4.x) and the ipa-replica-install command completed successfully but now when I run the ipa-manage-replica -v list <host> command I see this:
# ipa-replica-manage -v list ipa5.domain.tld
Directory Manager password:
ipa1.domain.tld: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (3) Replication error acquiring replica: Unable to acquire replica: permission denied. The bind dn does not have permission to supply replication updates to the replica. Will retry later. (permission denied)
last update ended: 1970-01-01 00:00:00+00:00
I ran the ipa-replica-manage re-initialize and it runs successfully and the above permission denied error goes away but the host can not be connected to any other replicas, it no longer sees itself as a replica or csreplica. I assume this is due to the re-init. I'm leery of trying to force it to try and join and potentially cause more issues. I would appreciate any helpful suggestions.
5 years, 1 month
