Remote services are not You; they do work on your behalf. When a remote service authenticates to another service, it should not impersonate you. If you use a keytab issued to your princial (say yourname@YOUNGLOGIC.INFO) you are not going to be able to log in to things using password; The IdM server only allows on or the other credential to be active at any given time. Even if you do use the Keytab, if you need to have it in two locations, you need to copy it. Which becomes a nightmare if it gets compromised. So, we want to make service accounts to work on our behalf. Here’s what I have so far.

Although My IdM server is not the definitive name server for my domain, I can add entries in to it to give it subdomains. So, I have created apps.demo.redhatfsi.com. I can make hosts under this to use as services, even though they are really going to all be on one IP address and exposed via a wildcard DNS entry. For this sample I have a host named sampleapp.apps.demo.redhatfsi.com. I might end up creating a DNS entry for it eventually, but I don’t need it at the moment. Just the IdM Host record is sufficient.

Under that host I created a service called custom. That leads to the full principal name of custom/sampleapp.apps.demo.redhatfsi.com@REDHATFSI.COM

I’ve granted permission to the ayoung user to both create and fetch the keytab (using the Web UI, a nice extension, props to the coders!). To actually fetch it, I log in to an ipa-client machine, kinit as ayoung, and run:

ipa-getkeytab -k custom.keytab -p custom/sampleapp.apps.demo.redhatfsi.com@REDHATFSI.COM

I can now use that to run kinit. Note that I need to pass the principal name in, as well as the file where the keytab resides:

kinit -t custom.keytab  custom/sampleapp.apps.demo.redhatfsi.com@REDHATFSI.COM

I can use this in a “curl with negotiate” call like this:

curl --negotiate -u custom/sampleapp.apps.demo.redhatfsi.com@REDHATFSI.COM: https://idm.redhatfsi.com/ipa/