I'm pretty sure ya'll are tired of my stupid questions, but I've got that new Geek smell with regards to IPA, and definitely with manual configuration. This should be easy to answer. I've got all the necessaries manually setup and I'm at the step to get the certificate from the IPA server. TFM states this is the correct syntax to do so:
[root@ipaclient ~]# ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM'
The problem I'm having is with the HOST/ and CN options, the reason being that the host I'm enrolling doesn't have the same domain name as the IPA server I'm using. The client is 'rad.astacalska.net' and the IPA server domain (and realm) is neonova.net. In IPA the client principal alias is host/rad.astacalaska.net@NEONOVA.NET. I tried this:
ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/rad.astacalaska.net -N 'CN=rad.astacalaska.net,O=NEONOVA.NET'
But after this completes (without an error I might add) and I try to su into my IPA account on the server I get 'unknown user'. I'm almost certain I've got things configured correctly except for this last bit. This box is on a /very slow/ link and the getcert was almost instantaneous, which makes me wonder if the command is wrong. I can post logs if need be, but getting them is time consuming so this might be a long troubleshooting process. So, is the command above correct? Or should it be changed?
Mark Haney via FreeIPA-users wrote:
I'm pretty sure ya'll are tired of my stupid questions, but I've got that new Geek smell with regards to IPA, and definitely with manual configuration. This should be easy to answer. I've got all the necessaries manually setup and I'm at the step to get the certificate from the IPA server. TFM states this is the correct syntax to do so:
[root@ipaclient ~]# ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM'
The problem I'm having is with the HOST/ and CN options, the reason being that the host I'm enrolling doesn't have the same domain name as the IPA server I'm using. The client is 'rad.astacalska.net' and the IPA server domain (and realm) is neonova.net. In IPA the client principal alias is host/rad.astacalaska.net@NEONOVA.NET. I tried this:
ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/rad.astacalaska.net -N 'CN=rad.astacalaska.net,O=NEONOVA.NET'
You may want host/... instead of HOST. Case matters for Kerberos principals (but the strings are more or less semi-established "standards"). Strictly speaking the prefix doesn't matter, it provides a "bucket" so IPA knows where to store the cert. If you use host/ it won't conflict with any other host entries and won't require a separate service entry.
Differing hostnames are allowed but the other host name(s) need to have host entries in IPA and it needs to be delegated to the enrolled name (managed by in IPA-speak).
But after this completes (without an error I might add) and I try to su into my IPA account on the server I get 'unknown user'. I'm almost certain I've got things configured correctly except for this last bit. This box is on a /very slow/ link and the getcert was almost instantaneous, which makes me wonder if the command is wrong. I can post logs if need be, but getting them is time consuming so this might be a long troubleshooting process. So, is the command above correct? Or should it be changed?
ipa-getcert is asynchronous so you submit a request and a daemon takes care of the rest. ipa-getcert list will show you the status.
A cert isn't required for basic sssd operation.
I think you just need /etc/ipa/default.conf, /etc/sssd/sssd.conf and a keytab but I haven't done a manual configuration in many moons.
By default sssd does very little logging. You might try bumping up the log level so you can see what is going on with the box, whether it can connect to IPA, etc.
rob
On 10/13/2017 09:17 AM, Rob Crittenden wrote:
Mark Haney via FreeIPA-users wrote:
I'm pretty sure ya'll are tired of my stupid questions, but I've got that new Geek smell with regards to IPA, and definitely with manual configuration. This should be easy to answer. I've got all the necessaries manually setup and I'm at the step to get the certificate from the IPA server. TFM states this is the correct syntax to do so:
[root@ipaclient ~]# ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM'
The problem I'm having is with the HOST/ and CN options, the reason being that the host I'm enrolling doesn't have the same domain name as the IPA server I'm using. The client is 'rad.astacalska.net' and the IPA server domain (and realm) is neonova.net. In IPA the client principal alias is host/rad.astacalaska.net@NEONOVA.NET. I tried this:
ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/rad.astacalaska.net -N 'CN=rad.astacalaska.net,O=NEONOVA.NET'
You may want host/... instead of HOST. Case matters for Kerberos principals (but the strings are more or less semi-established "standards"). Strictly speaking the prefix doesn't matter, it provides a "bucket" so IPA knows where to store the cert. If you use host/ it won't conflict with any other host entries and won't require a separate service entry.
I tried changing HOST/ to host/ and got this: Certificate at same location is already used by request with nickname "20171013123749"
Seems it doesn't matter on this setup. Oh, probably should mention this is a CentOS 6.9 box. In case that matters.
On 10/13/2017 09:48 AM, Mark Haney wrote:
I tried changing HOST/ to host/ and got this: Certificate at same location is already used by request with nickname "20171013123749"
Seems it doesn't matter on this setup. Oh, probably should mention this is a CentOS 6.9 box. In case that matters.
Okay, we're getting somewhere now. Turns out I'm a giant moron. The krb5.conf file I was using was incorrect. The domain_realm section didn't include the 'astacalaska.net' bit. So, when I got that fixed and issued a new getcert request, I have a new error:
Request ID '20171013140647': status: CA_UNCONFIGURED ca-error: Error setting up ccache for "host" service on client using default keytab: Generic preauthentication failure. stuck: yes
I'd be more specific, but this was a really generic error message.
Mark Haney wrote:
On 10/13/2017 09:48 AM, Mark Haney wrote:
I tried changing HOST/ to host/ and got this: Certificate at same location is already used by request with nickname "20171013123749"
Seems it doesn't matter on this setup. Oh, probably should mention this is a CentOS 6.9 box. In case that matters.
Okay, we're getting somewhere now. Turns out I'm a giant moron. The krb5.conf file I was using was incorrect. The domain_realm section didn't include the 'astacalaska.net' bit. So, when I got that fixed and issued a new getcert request, I have a new error:
Request ID '20171013140647': status: CA_UNCONFIGURED ca-error: Error setting up ccache for "host" service on client using default keytab: Generic preauthentication failure. stuck: yes
I'd be more specific, but this was a really generic error message.
So yeah, you've moving right along. I was in the middle of asking you to check krb5.conf when this one came in :-)
So the reason the resubmit failed is certmonger tracks the location, etc for certs to prevent duplicates (and racing at renewal time). You can either drop a request using ipa-getcert stop-tracking -i <id>
Or ipa-getcert resubmit -i <id> ...new-or-changed-options...
The first is probably "cleaner" esp since you don't yet have a valid cert.
I'd check for SELinux issues on /etc/krb5.keytab. Perms should be 0600 root:root.
Or maybe it's the keytab itself. You can tell via:
# kinit -kt /etc/krb5.keytab
You need a key for the value of `hostname`.
But again, a cert isn't required for successful IPA integration. We thought it would be a nifty future-proofing idea to have a cert on all clients. We were wrong and no longer do it.
rob
On 10/13/2017 10:21 AM, Rob Crittenden wrote:
So yeah, you've moving right along. I was in the middle of asking you to check krb5.conf when this one came in :-)
So the reason the resubmit failed is certmonger tracks the location, etc for certs to prevent duplicates (and racing at renewal time). You can either drop a request using ipa-getcert stop-tracking -i <id>
I stopped tracking the old request and submitted a new one.
I'd check for SELinux issues on /etc/krb5.keytab. Perms should be 0600 root:root.
SELinux is disabled on this box and permissions are correct.
Or maybe it's the keytab itself. You can tell via:
# kinit -kt /etc/krb5.keytab
You need a key for the value of `hostname`.
This is what I get when checking the keytab itself:
kinit -kt /etc/krb5.keytab kinit: Generic preauthentication failure while getting initial credentials
When I ran this on one of the other AK boxes I get no output at all. Granted, all but 2 of these AK boxes were setup using ipa-client-install, so I don't know if that matters or not.
Mark Haney via FreeIPA-users wrote:
On 10/13/2017 10:21 AM, Rob Crittenden wrote:
So yeah, you've moving right along. I was in the middle of asking you to check krb5.conf when this one came in :-)
So the reason the resubmit failed is certmonger tracks the location, etc for certs to prevent duplicates (and racing at renewal time). You can either drop a request using ipa-getcert stop-tracking -i <id>
I stopped tracking the old request and submitted a new one.
I'd check for SELinux issues on /etc/krb5.keytab. Perms should be 0600 root:root.
SELinux is disabled on this box and permissions are correct.
Or maybe it's the keytab itself. You can tell via:
# kinit -kt /etc/krb5.keytab
You need a key for the value of `hostname`.
This is what I get when checking the keytab itself:
kinit -kt /etc/krb5.keytab kinit: Generic preauthentication failure while getting initial credentials
When I ran this on one of the other AK boxes I get no output at all. Granted, all but 2 of these AK boxes were setup using ipa-client-install, so I don't know if that matters or not.
Sounds like the keytab is out-of-sync. Try this:
# klist -kt /etc/krb5.keytab
Note the kvno
On a machine you can kinit on:
$ kinit admin $ kvno <principal of non-working client)
The kvno should match that of the keytab. If not you'll need to regenerate it.
Note that by default ipa-getkeytab generates new keys every time it is executed.
rob
On 10/13/2017 11:23 AM, Rob Crittenden wrote:
Sounds like the keytab is out-of-sync. Try this:
# klist -kt /etc/krb5.keytab
Note the kvno
On a machine you can kinit on:
$ kinit admin $ kvno <principal of non-working client)
The kvno should match that of the keytab. If not you'll need to regenerate it.
Note that by default ipa-getkeytab generates new keys every time it is executed.
rob
The kvno matches: KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET
kvno host/rad.astacalaska.net@NEONOVA.NET host/rad.astacalaska.net@NEONOVA.NET: kvno = 1
On a side note, on the problem box, I can 'kinit admin' and supply the correct NEONOVA.NET admin password without problems. If I do a 'klist' with no params, I get this: klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin@NEONOVA.NET
Valid starting Expires Service principal 10/13/17 10:13:37 10/14/17 10:13:05 krbtgt/NEONOVA.NET@NEONOVA.NET
And when I run 'klist' on the server that I ran kvno on I get this:
[root@rad0 pki]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin@NEONOVA.NET
Valid starting Expires Service principal 10/13/17 12:57:04 10/14/17 12:56:51 krbtgt/NEONOVA.NET@NEONOVA.NET 10/13/17 12:57:33 10/14/17 12:56:51 host/rad.astacalaska.net@NEONOVA.NET
I can also run kvno on the problem server and it outputs the same:
[root@rad pki]# kvno host/rad.astacalaska.net@NEONOVA.NET host/rad.astacalaska.net@NEONOVA.NET: kvno = 1
So, I'm at a total loss as to the problem. It looks like IPA authentication works (at least with kinit), but it's not for other accounts.
On 10/13/2017 11:23 AM, Rob Crittenden wrote:
The kvno should match that of the keytab. If not you'll need to regenerate it.
Note that by default ipa-getkeytab generates new keys every time it is executed.
rob
Addendum to my previous reply. I /can/ 'kinit mark.haney' and supply my password on the problem box. It doesn't work when I try to su - mark.haney (user mark.haney does not exist) or sudo -u mark.haney (sudo: unable to initialize policy plugin). And as my user account has /never/ existed on this box either in LDAP or local, I know IPA auth is working for accounts, just not completely working.
On 10/13/2017 09:00 AM, Mark Haney wrote:
I'm pretty sure ya'll are tired of my stupid questions, but I've got that new Geek smell with regards to IPA, and definitely with manual configuration. This should be easy to answer. I've got all the necessaries manually setup and I'm at the step to get the certificate from the IPA server. TFM states this is the correct syntax to do so:
[root@ipaclient ~]# ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/ipaclient.example.com -N 'CN=ipaclient.example.com,O=EXAMPLE.COM'
The problem I'm having is with the HOST/ and CN options, the reason being that the host I'm enrolling doesn't have the same domain name as the IPA server I'm using. The client is 'rad.astacalska.net' and the IPA server domain (and realm) is neonova.net. In IPA the client principal alias is host/rad.astacalaska.net@NEONOVA.NET. I tried this:
ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/rad.astacalaska.net -N 'CN=rad.astacalaska.net,O=NEONOVA.NET'
But after this completes (without an error I might add) and I try to su into my IPA account on the server I get 'unknown user'. I'm almost certain I've got things configured correctly except for this last bit. This box is on a /very slow/ link and the getcert was almost instantaneous, which makes me wonder if the command is wrong. I can post logs if need be, but getting them is time consuming so this might be a long troubleshooting process. So, is the command above correct? Or should it be changed?
Here's some additional information I've slowly been able to glean from this server. When I run 'ipa-getcert list' I get this:
Request ID '20171013123749': status: CA_UNCONFIGURED ca-error: Error setting up ccache for "host" service on client using default keytab: Keytab contains no suitable keys for host/rad.astacalaska.net@.
Seems the realm is missing. Could this be from the incorrect ipa-getcert request? The keytab is correct AFAICT:
klist -kt rad.astacalaska.net.keytab Keytab name: FILE:rad.astacalaska.net.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET 1 10/12/17 14:37:41 host/rad.astacalaska.net@NEONOVA.NET
FYI, this is the krb5.keytab file on the server. It had to be generated on a localhost due to latency issues. Does this help?
freeipa-users@lists.fedorahosted.org
-
Mark Haney -
Rob Crittenden