Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?
Greetings, * Ken Hornstein via Kerberos (kerberos@mit.edu) wrote: > >Has anyone else struggled with ssh clients being unable to delegate > >As far as we can tell, for reasons we still have been unable to > >fathom, Microsoft decided that simply permitting credential delegation > >based on whether the TGT has the forwardable flag set was > >insufficient. Instead, Microsoft implemented a new flag in the MS-SFU > >Kerberos Protocol Extensions, TRUSTED_FOR_DELEGATION. The flag is a > >property of the service principal of the *target* host: if the target > >host does not have the TRUSTED_FOR_DELEGATION flag set in the > >userAccountControl attribute of the host’s machine account in Active > >Directory, then if the Kerberos library that the ssh client uses > >honors the MS-SFU Kerberos Protocol Extensions and honors the > >TRUSTED_FOR_DELEGATION flag, it will refuse to delegate the user’s > >credentials to the target host, *even* if all other settings would > >permit credential delegation. > > I'm a LITTLE confused as to what you're describing here. As I > understand you, the TRUSTED_FOR_DELEGATION flag doesn't appear on the > wire and only in the account properties. What, exactly, is there for a > client implementation to honor or not honor? If you're talking about > the OK-AS-DELEGATE flag in the Kerberos ticket, MIT Kerberos does > implement that flag (but ... the library already provides an option > to ignore that flag and it seems that by default it DOES ignore that > flag). It seems like some versions of Heimdal also will ignore the > OK-AS-DELEGATE flag by default and you can configure Heimdal to respect > that flag but I am unclear what the OS X Heimdal does. Calling that a > Microsoft extension is incorrect, though, as that appears in RFC 4120. > As for the thinking behind this flaga, well, the RFC provides what I > would consider a cognizant explanation: > > https://datatracker.ietf.org/doc/html/rfc4120#section-2.8 > > If you're talking about something else, I would be curious as to what > you mean. I didn't think ssh could utilize any of the S4U stuff > but it's always possible that could have changed. Before delving too deeply here ... frankly, I'd *strongly* encourage you to ignore what OSX comes with in terms of Kerberos "support" and push to move everything away from what OSX ships with and to instead use MIT Kerberos. In my experience, this is far from the only issue you're going to run into with the hacked up Kerberos from OSX and they don't seem to care to properly maintain it. Thanks, Stephen signature.asc Description: PGP signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberos client on windows not being able to access credentials cache ("Internal credentials cache error")
Greetings, * Tomas Pospisek (t...@sourcepole.ch) wrote: > In case anybody is interested (or as a reference for future readers): I was > able to resolve the problem. See > https://www.postgresql.org/message-id/08b836a7-272a-2309-da45-ac691fccacb8%40sourcepole.ch > for details. Yes, you're welcome. > Also, since I got precisely zilch feedback here while there were other > postings here I'm under the impression that this is a mailing list with *no* > user support (but instead a development list or similar). If that's the > case, then it would be certainly helpful for other similar poor mislead > souls like me to have that characteristic of the mailing list documented on > it's page: http://web.mit.edu/kerberos/new/mail-lists.html ... This list can be quite valuable but, just like the PG lists, people aren't paid to be on here helping you out. If you'd like support for all this great free software that you're using that a lot of people spend time and effort building and maintaining, I'd suggest you procure it- that would allow us to continue to develop it further too. I don't pay as much attention to this list, but I do monitor it and had I not already replied to your other email, likely would have replied here too, except that the expectation that I, or someone else on this list is required to do so sure reduces one's enthusiasm to. Thanks, Stephen signature.asc Description: PGP signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: pam-krb5 4.5 released
Greg, * Greg Hudson (ghud...@mit.edu) wrote: I can think of several things to worry about with that: Thanks for your thoughts! It strikes me that the KDC has all the pieces needed to make the decision. The only question is if the right parts have the necessary information to check. My gut feeling is that the SAM2 module should be able to tell if FAST is being used and, if not, refuse to allow progress to go forward. This would have to be configurable on the KDC side, of course, but I think it would address the concerns you raised. I've not looked at any of the code associated with this yet, but I plan to do so over the next few days to see if my suggestion above can be implemented. Regarding configuration management and trusting the securID implementation- those are certainly valid concerns and should be documented. I'm confident in our securID implementation (which includes both long PINs and long token values) and feel we can manage the configuration pieces (particularly ensuring that we only set 'simple' passwords on princs which have require_hwauth set; perhaps we could set a policy of some kind associated with that..). Thanks again! Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: pam-krb5 4.5 released
Russ, all, * Russ Allbery (r...@stanford.edu) wrote: I'm pleased to announce release 4.5 of pam-krb5. As this is the users list that pam-krb5 is announced on, I figured this would be an alright place to ask a few questions about both it and the MIT KDC. First- I *think* I've done everything correct to get pam-krb5 to use FAST (which is to say, set up k5start, verified it gets a valid ticket, configured krb5.conf w/ the fast_ccache parameter, etc), but I have no idea how to tell if it's *actually* getting used. I'm using the 'stock' config of the MIT KDC from Ubuntu, with the slight caveat that I made the RSA SDK available, so it includes SAM2 and secureID support. Regarding securID support- that all seems to be working just fine from kinit and through ssh/pam-krb5 (with ChallengeResponse and PAM enabled, of course). However, as you might expect, both pam-krb5 (as tested with OpenSSH) and kinit prompt for the principal's 'normal' password before prompting for the token code (and it cares- it won't work if you don't provide the correct PW). Is there any way to eliminate the need for this first password? I had been hoping that FAST would take care of it, or that, with FAST, I could remove the requires_preauth flag from the princ and that it wouldn't require the initial password, but neither of those seemed to work. Would the pkinit approach work better to allow this setup to work as I desire? Any thoughts or pointers on this would really be appreciated. I feel very, very close to having a good, working solution which leverages Kerberos, RSA/securID, and SSH. I've been hoping for this combination to work nicely for, literally, *years*. Thanks! Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: pam-krb5 4.5 released
Russ, * Russ Allbery (r...@stanford.edu) wrote: Yes, I have a pending patch to allow you to disable all password prompting behavior in the module because you're using some other mechanism than password and want the Kerberos prompter to just take care of it all. I'm going to try to get out a new release with that change this month. There currently isn't a way to avoid that password prompt, unfortunately. Great, thanks! I'll give the patch a try early next week. Do you have any suggestions about how to tell if FAST if being used by pam-krb5, etc? I've looked through the auth.log on the host and the KDC, enabled debug in the pam-krb5 config, and generally looked around to see if I could figure it out. Unfortunately, nothing appears to indicate one way or the other. I'd just like to make sure that the conversation is being protected with a good key. Thanks again! Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: pam-krb5 4.5 released
* Greg Hudson (ghud...@mit.edu) wrote: Is there any way to eliminate the need for this first password? Not with the securid-sam2 preauth module. It implements the send-encrypted-sad method of SAM2 preauth, which requires the user's long-term key to be used to encrypt the OTP value. Ok, thanks. Is the user's long-term key of any value if FAST is in place? By that I mean- could I just make it 'password' or similar without any security risk..? Thanks! Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: RFC: Turning off reverse hostname resolution by default in 1.10
* ghud...@mit.edu (ghud...@mit.edu) wrote: Does anyone on this list intentionally rely on PTR lookups for Kerberos hostname canonicalization? Yes, all the time. Dealing with the Windows world and cross-realm, where a machine can only ever have one name, has always been very painful, I'd hate to see MIT Kerberos go the same way. Thanks, Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Multi Realm Question
* Tom Parker (tpar...@cbnco.com) wrote: I am trying to avoid the need for a 3rd authentication server at my remote sites (XX.EXAMPLE.COM master and slave + EXAMPLE.COM slave) Have you considered just running multiple kdc processes..? I'd think you could do more than one on a single box, but even if that's problematic, you could always use something like Linux VServer or Linux Containers to segregate a single box into multiple virtual systems... Thanks, Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Putty + GSSAPI from W2k3 terminal server to linux openssh daemon
* Jonathan Barber ([EMAIL PROTECTED]) wrote: We don't have any particular preference WRT ssh clients, putty was just choosen as our test as it's what we have used in the past. This thread got me curious, and it appears that ~2 months ago, GSSAPI support was committed to the PuTTY subversion tree. Anyone tried it? I'd love to move off of all of these hacked/patched versions of PuTTY that are floating around. We're currently using http://sweb.cz/v_t_m/#putty but in the past we've used a variety of things. :/ Thanks! Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.
* Mikkel Kruse Johnsen ([EMAIL PROTECTED]) wrote: Now I only have the problem that mod_auth_kerb don't write my credentials to KRB5CCNAME (in PHP). My kerbtray under windows says it is Forwardable but no Ok to delegate, So I guess that is the problem. Under linux they are forwardable. [...] I found how to set ok-as-delegate for heimdal how is this done for MIT kerberos ? The short answer is, you don't. For reasons unknown to me, the MIT Kerberos upstream folks have seen fit to implement something in their client libraries that's not done in their server. This means that even a completely MIT solution breaks. We've heard of some patches going around to implement the ok-as-delegate flag in the MIT KDC but havn't been able to actually get a hold of them yet. If we're unable to we might end up writing some ourselves as this is rather important to us. If we find or write patches to fix this glaring problem in the MIT KDC we'll be sure to post them. Thanks, Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: KRB5CCNAME is not reread
* Jeffrey Altman ([EMAIL PROTECTED]) wrote: Russ Allbery wrote: Brian C DeRocher [EMAIL PROTECTED] writes: They have the form /tmp/krb5cc_apache_xx. Each web request has a different suffix. However mod_php stays in memory. It appears that libkrb5 doesn't check if KRB5CCNAME has changed. mod_php would need to close and reopen the ticket cache, I believe, to pick up the change in the default ticket cache name. KRB5CCNAME is an environment variable that is used by the krb5 library to obtain the default credential cache name. This is used when the application chooses to open the default credentials cache. The application passes a handle to the credential cache to the library with each call. If the credential cache needs to be changed, it is the responsibility of the application to make that decision. Fair enough, so perhaps PostgreSQL isn't doing something quite right. Here's what it's doing inside PQconnectdb() wrt krb5, in a nutshell: krb5_init_context(pg_krb5_context); krb5_cc_default(pg_krb5_context,pg_krb5_ccache); krb5_cc_get_principal(pg_krb5_context, pg_krb5_ccache, pg_krb5_client); krb5_unparse_name(pg_krb5_context, pg_krb5_client, pg_krb5_name); krb5_sname_to_principal(pg_krb5_context, hostname, servicename, KRB5_NT_SRV_HST, server); krb5_sendauth(pg_krb5_context, auth_context, sock, servicename, pg_krb5_client, server, AP_OPTS_MUTUAL_REQUIRED, NULL, 0, pg_krb5_ccache, err_ret, NULL, NULL); krb5_free_principal(pg_krb5_context, server); It doesn't appear to do anything wrt krb5 in PQfinish(). Now, between the two PQconnectdb() calls the KRB5CCNAME environment variable changes, which means that it's different between the first krb5_cc_default() call and the second, yet the second call doesn't seem to notice this. It looks like pg_krb5_ccache is actually a static variable- if that's not empty when krb5_cc_default() is called does krb5_cc_default() just leave it as-is? Looking at this more closely I'm starting to think the problem is with PostgreSQL after all. :/ Thanks for the comments, Stephen signature.asc Description: Digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Why sometimes we got credential /tmp/krb5cc_uid_xxxx?
* Douglas E. Engert ([EMAIL PROTECTED]) wrote: This would be a session cache, and would be created by sshd for example. the x is mean to make the name unique. You would want a different cache for each session, so the sessions would not interfer with each other. The sshd would also set the KRB5CCNAME env to point to the cache. [...] Its a feature not a problem. Actually, it's a rather annoying problem, but not an insurmountable one. I've set up my shell scripts to do what I consider the 'right' thing. Basically they move the forwarded tickets provided by sshd into place, overwritting anything there and then keep a session counter and kdestroy when the last session has exited. This means I can use forwarded tickets with screen and things actually work even when I detach, logoff, logon and reattach to screen. If anyone's curious in the shell script bits (they're not complex) I'd be happy to make them available. Stephen pgp0.pgp Description: PGP signature Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
