On 09/25/2014 02:44 PM, Nordgren, Bryce L -FS wrote: The configs do not talk about SSSD at all. This area definitely requires some face lift. I wounder if they are aware about SSSD and IdM? Any chance someone can ask them to consider SSSD and IdM using SSO as you described above? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.

I guess a fundamental question is: how would a FreeIPA/sssd compute cluster handle a "batch job/queue submission workflow"? For instance, I submit my job now, with my active ticket. It runs tomorrow, when ticket is expired. Some available GSSAPI integration hooks in "Son of Grid Engine" are here : http://arc.liv.ac.uk/repos/hg/sge/source/security/gss/doc/gss_customer.html What's missing and how would the queueing system need to interact with FreeIPA/sssd? Interesting conference proceeding from 2001. A little dated, but you can see how they guided some GSSAPI/Kerberos development in the 2000's. http://www.sc2001.org/papers/pap.pap192.pdf Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

I agree that it looks like it's sending TGT around, and this exposes the user to the possibility that the TGT will expire before the job runs. If I understand GSS proxy right, I provide a keytab with my password in it so that it can get a TGT as me whenever it wants. The keytab may not be human readable, but it is directly usable by kinit. This seems too much like typing my passwd into a plain text file. I also don't understand how s4u2proxy can be considered "constrained" delegation, or even really delegation: "The client has no control over whether a service can delegate on behalf of the user. The client does not request delegation nor does it pass a forwardable TGT to the service. The client cannot detect that delegation will be, or has been, performed. If local policy allows the service to perform S4U2proxy delegation, this delegation is performed solely at the discretion of the service." It sounds more like identity appropriation to me. Like "su - <username>" by root. Of the two, I suspect I'd prefer s4u2proxy if: a] s4u2proxy can acquire a forwardable TGT; and b] the only thing which can impersonate me is the queue master. In any case, this is a band-aid, as jobs may run longer than a TGT is valid (say a week or more). What if gss-proxy were given a proxy certificate (RFC3820) instead of a keytab file? PKINIT to the KDC to maintain the TGT. Plusses are that long running jobs could always have a current TGT. Minuses: same issues as a keytab file; anyone with the proxy can be me. OTOH, dogtag's secure store could be set up only to release the proxy certificate to authenticated Kerberos principles (e.g., the gss-proxy services). I'm sort of liking that. We'd just have to make sure that part of the queue submission process is the issuing of a proxy certificate for the queue manager to act as me. Users could be sent a warning if their proxy certificate is going to expire and instructions on how to extend the proxy. Also want to check to make sure this can be done without fiddling with the queue manager's internals. This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

Ah. I had to give k5start a keytab with my encrypted password in it. It doesn't have its own Kerberos identity. How does gss-proxy authenticate as me, then? Wouldn't my service ticket expire at the same time my TGT does? How does this help me make sure my ticket stays valid for the life of my long lived process? The part in quotes was from the Microsoft website explaining how s4u2proxy works. Bullet #1 (not quoted), seems to say the opposite of the above. The verbatim quote is from the fourth bullet point, here: http://msdn.microsoft.com/en-us/library/cc246079.aspx I would be very happy to learn that this is a mistake, but their page is clear to the point of being emphatic. Ah, so we're back to "what's in the keytab?" If it's gss-proxy's keytab, what does it have to do with me? How does my identity get delegated? In any case, keytabs are long term secrets (for users or services), and proxy certificates are not. If I'm going to give something access to my identity, I don't want to be giving it my long term secret (password), but I do want to give it _something_! It's also my understanding that DogTag is set up to securely store certificates, controlling their release to authorized parties. I am not aware of a similar service for keytabs. This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

OK, so the default rocks config is that authentication to the compute nodes is handled via ssh key, and the queue master has access to everyone's private key by virtue of being a privileged process on the head node. This proposed situation is functionally similar in that the KDC would be configured to allow the queue manager to impersonate users as necessary in order to start jobs. The impersonation can take the form of a forwardable TGT (I hope) which can be used to start jobs via ssh across the cluster, providing each node access to data on shared filesystems. The main improvement is that long term secrets are better protected (publishing home directories containing private keys to the cluster via NFS w/sec=sys vs. a single unpublished keytab which unlocks all identities.) As I understand it put_cred will need to be rewritten to support S4U mechanisms, in case the job has been queued long enough that the tgt has expired. A remaining question is "what prevents the tgt/service tickets from expiring during a running job causing my process to lose access to my shared filesystem"? Would each compute node need to be running a service which can s4u2self/proxy? Is that service gss-proxy? A second barrage of questions: when I was experimenting with PKINIT, the MIT Kerberos KDC would not issue a TGT unless the user existed in its local database, and the local database needed to have principals in the local realm. Can you S4U2self/proxy to impersonate a non-local user without actually creating a cross-realm principal in the local KDC (e.g., client principal is user/AD.EXAMPLE.COM(a)LOCAL.EXAMPLE.COM)? Can you S4U2self/proxy to impersonate a user where the user's realm is not local (e.g. user(a)AD.EXAMPLE.COM)? The latter is ideal, and maybe necessary to avoid a messy many-to-one principal to identity mapping (not to mention a fundamental overhaul of sssd's concept of "domains".) My apologies for obfuscating the difference with my ignorance. I fear I misspoke when I assumed that one could use the proxy certificate (PC) to PKINIT. The subject of the PC is a kind of "augmented" user subject (issuer+single common name element per proxy). [1] A PC is also forbidden to have a "subjectAltName" [1], which is required by a PKINIT-able kx509 certificate. I think these PCs are for use with 'GSI-enabled OpenSSH' [2] which is available in EPEL and Fedora. Kerberos can't use them, but potentially an S4U enabled gateway service could. An RFC3280 Proxy Certificate does not expose your private key. The derived keypair (which is given to the service but which is not exposed to you) is designed to be more similar to a longish-lived proxiable service ticket than a password/keytab due to its limited lifetime and embedded constraints. The proxy certificate should spell out the constraints on the delegation using publicly documented policy languages, whereas providing a keytab is unconstrained. (The "catch" is that there are no currently defined languages in the IANA registry [3].) S4U constraints are KDC implementation specific and not-communicate-able between clusters within a grid (and I suspect they are not embodied in the ticket either). I do not believe there is a means to translate standardized constraints in the PC (assuming a policy language is developed) to the Kerberos ticketing system. For that matter, I do not believe I have seen evidence that Kerberos tickets have a mechanism to refer to a vocabulary to express constraints. If a gateway were to exist, it would have to restrict itself to requesting proxiable service tickets for the particular services delegated in the PC. (Or grant a TGT for the special "inheritAll" value.) The question is: Is constraint really necessary, or is delegation all that is required? The most common use case may be to execute your job as you...Constraining things may just lead to problems... The downside, of course, is that a PC is not a Kerberos ticket and doesn't provide access to a Kerberos-protected NFS export, even when it allows you to login and execute code. Also, translating from GSI certificates to local identities is a big blank spot on my mental map. Here there be dragons. Fundamentally I don't want to learn anything new, I want cluster user management to leverage the same set of tools the rest of my machines do. :) Like FreeIPA+views/sssd. Add a gateway if you join a grid. [1] http://www.ietf.org/rfc/rfc3820.txt [2] http://grid.ncsa.illinois.edu/ssh/ [3] https://www.ietf.org/assignments/proxy-languages/proxy-languages.xml Thanks, Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

On 10/04/2014 06:17 PM, Nordgren, Bryce L -FS wrote: IN case of S4U2self/proxy you do not need to give the master private keys to impersonate people. You just need to have a policy saying that it can impersonate using its own key. That is the difference. With S4U2 the TGT is not forwarded. When TGT is forwarded them the impersonation is unconstrained. With S4U2 the delegation is constrained to impersonate only in relation to the specified target services and not anything else. I think so. There are two parts. First of all gss-proxy helps you with privilege separation and s4u2 part. Second the kerberos library itself is now capable of acquiring the ticket on demand as needed. So even if there is no ticket available because it expired the service would be able to conjure one on demand. I do not think it can. However with some sort of SAML bridging between realms it might be able to in future. For example you have an instance of a service that does file operations on your behalf. The file operations are kerberized. The service is a web service. You have user U in realm A and corresponding user in realm B. Realm A is the home user realm (AD) and B is the service realm (in this case NFS storage realm but OpenStack can be another example). User hits web interface of the service; service redirects user to IdP; IdP is in realm A; it uses kerberos ticket in realm A for IdP to authenticate user; IdP creates and assertion and redirects back to service; service takes assertion, maps it to account in realm B and does s4u2self/proxy on user behalf. No the operation can be complete in realm B. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.