> Hi again, I am looking at the implementing this (getting Kerberos
>service token) in C using Heimdal Kerberos library. In Golang using
>this go package https://github.com/alexbrainman/sspi it was simply two
>calls as below:
>
>cred=negotiate.AcquireCurrentCredentials()token =
>I looked at the Apple fork of Heimdal and didn't find any obvious code
>change to honor ok-as-delegate by default. In fact, it doesn't even
>implement enforce_ok_as_delegate. But both versions do implement a
>ccache config setting called "realm-config" and enforce ok-as-delegate
>if the 1
>I think the core issue here is that RFC4120§2.8 was unclear in
>defining the ok-as-delegate flag.
I have to say that IMHO, the explanation in RFC 4120 is clear to me
and the current implementations within the MacOS X Kerberos code fall
squarely within the scope of the RFCs explanation. The
>User acquires kerberos ticket and login session is authorized. This log
>is for a ssh access ...
I think you're missing some of the details that Greg is asking. When you
say "ssh access", do you mean that you are using gssapi-with-mic or
gssapi-keyex authentication with ssh, or does ssh ask for
>> 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.
>
>Yes. Apologies; I should have been more precise: when Microsoft AD is
>acting as the KDC, whether AD sets the the
>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
>- impersonate the user as, say, admin, with kinit; e.g. kinit
>- scan all HDFS directories and try to read or write
>
>Does anyone have suggestions?
In general, your options are:
- Have access to to user's key/password and generate a ticket for that
user using kinit. As someone else already
>Hi, I have an application that authenticates against a Proxy server
>which user Kerberos authentication scheme. My application is using SSPI
>library (github/alexbrainman/sspi Golang package to be exact) generate
>a kerberos token and this token is passed to the Proxy server through
>Are you familiar with https://github.com/jcmturner/gokrb5? I've used it
>in the past with some experiments in some Go code I was working on, I
>wasn't touching GSSAPI but there's at least some GSSAPI code in there.
>Might be worth checking out as it's native Go code, no cgo wrapping.
I would
>Thanks again Ken. My application is written in Go. So I'm looking
>for Kerberos implementation that can be easily integrated with my
>application. Hence I was considering MIT Kerberos and using C bindings
>to call those APIs from my Go code. "MacOS X it might be easier to use
>the native
>Thanks Ken,I understand I need to use GSSAPI for Linux/MacOS
>platforms. I was wondering if I can use MIT Kerberos GSSAPI for the
>same. Does libcurl use MIT Kerberos gssapi ? Yes my proxy header would
>look exactly like you mentioned. Thank-you.
You should be able to use the MIT Kerberos
>Hi, I have a requirement to authenticate my application
>(Golang) against a proxy server which requires Kerberos
>authentication. I have achieved this on Windows using
>github/alexbrainman/sspi Golang package.From that package I
>basically call negotiate.AcquireCurrentUserCredentials() and
>Is there a way when using PKINIT to not need any internal list of
>principals but to rely on the validity of the certificate to proxy the
>certificate identity into the Kerberos ticket?
I know what all of those words are, but I'm unclear what they mean all
together. I think you mean _this_
>Looking at Apple documentation I see the support for something I had
>never heard of: Kerberos Key Distribution Center Proxy.
>
>Looks like a solution to encapsulate Kerberos requests into an HTTPS.
>
>Any experience on this here?
I personally have not used that, but I know that MIT Kerberos
>> A long time ago we had developed a small Kerberos proxy that forwarded
>> on Kerberos messages by prepending the source IP address/port to the
>> UDP message (our KDC at the time was modified to recognize this and
>> sent the prepended bytes back to the proxy so it could send it to the
>>
>> One thing that leaps out at me is that by default a lot of Kerberos
>> messages default to UDP transport so that might be a bit trickier to
>> proxy them (but not impossible).
>
>Yes, that's another aspect of the issue, our expectations so far are on
>support for TCP only clients. Since it's
>Here with Kerberos, I'm wondering how we can achieve something
>equivalent, using a shared IP for multiple Kerberos realms and having
>the incoming requests routed to the appropriate backend by some kind of
>inspection.
I think that is certainly _possible_, but I don't believe there is
anything
>We did a server replacement of our master KDC that had been on RHEL7
>for years to finally upgrade to RHEL8. We did a dump of the database
>prior to the swap, we still have the old server sitting around as
>well. Principal database is on disk in old db2 style. Kerberos
>version is 1.18 for
>Hi, We can generate a TGS with GSS API in Java.
>But is there a way to get TGT in java, assuming I have account/password?
With the pure, standards based GSS, the answer is "no". There is
this, but I do not know if all Java implementations support it:
>We have a setup where the kerberos database (db2) is hosted on an NFS
>server. There are multiple KDC servers each mounting the NFS share and
>serving traffic.
I have to say up front that it is generally agreed that putting any database
file on a NFS filesystem is a bad idea. Also, it kind of
>This approach is taught in first year engineering.
Geez dude, no need to drag me; I'll be the first one to admit that I'm old
and don't know everything! Back in my day our curriculums didn't cover
any computer security topics at all.
But I stand by my original statements: I, personally, have
>Minor comment the CIS Benchmark appears to have been written from the
>system administrator's frame of reference - not the network frame of
>reference (FoR). Typically, each frame of reference (FoR) needs to be
>audited. Hence the need for automation.
I can only say this:
- I've been doing
>Its good to know the reason why MIT Kerberos cannot handle EC
>certificates right now.
I think it's important to be specific here; the issue is specifically
a PKCS#11 token; Greg has already said that a software ECC certificate & key
work fine.
>So is there a way to submit a feature request
>Indeed. Unfortunately my stock packages on CentOS 9 Stream are 1.21
>but the KRB5_TRACE feature was introduced in 1.9.
Ummm ... 21 > 9, I think? :-)
>At any rate, of course I figured out the problem right after posting this ...
Glad you figured it out.
--Ken
You MIGHT be better served by turning on Kerberos tracing to see what the
library is doing. Prefixing that kinit with:
env KRB5_TRACE=/dev/stdout
would be useful. However, assuming these are in order ...
>ProtocolLength Info
>DNS 80 Standard query 0xd8af A dc1.gogo.loco
>DNS 96
>We had it working in November with Yubico's libykcs11 in a lab and in
>production tested by two independent people. Testing it again this year
>it failed. We are in the process of finding out what exactly we have
>tested in November.
>
>I am really confused now. I thought that the problem was
>Krb5 devs,
I'm not an official MIT krb5 developer, so I can't speak for them. But
in my experience things like this tend to be the most successful when they
are submitted as pull requests. That was my plan, eventually.
>Any thoughts about extending kinit to natively perform the two step
>1. For the kinit -l and -r, I will get started on changing everything to be
>the same thing. When I finish, I will email back to you if I was successful
>and if not I will send screenshots of the configs.
Note that while I am glad to help, I can't guarantee that I'll be
available for unlimited
> - How do we extend ticket lifetime to 14 days?
> - We have tried to set the ticket lifetime to 14 days in krb5.conf
> [realm] but it caps out to one day
First, assuming you're talking about the "ticket_lifetime" parameter,
that actually goes in the [libdefaults] stanza. You can
>> However, I believe Yubico provides a PKCS#11 module for Yubikeys; have
>> you tried that? The OpenSC people usually do a good job in terms of
>> supporting a wide variety of cards but depending on how old the particular
>> version of OpenSC you are using is you may be running into a
>I would be happy to have more trace logging to diagnose PKINIT errors,
>but converting every pkiDebug() call probably wouldn't meet the criteria
>for good trace logging. We've already made a few passes in this area,
>most recently one from you which went into release 1.20 (commit
>P:296321; T:0x140609979246400 17:33:26.054 [opensc-pkcs11]
>pkcs11-object.c:697:C_SignInit: C_SignInit() = CKR_KEY_HANDLE_INVALID
As a follow-up to my previous message, I believe the problem is that for
_smartcards_ the PKCS#11 mechanism is hardcoded to CKM_RSA_PKCS:
/*
* We'd like to
>P:296321; T:0x140609979246400 17:33:26.054 [opensc-pkcs11]
>pkcs11-object.c:697:C_SignInit: C_SignInit() = CKR_KEY_HANDLE_INVALID
>
>So there is some problem with opensc-pkcs11. Interestingly I am using
>the same Yubikey successfully with pam-pkcs11 to authenticate without
>problems.
>On 11/15/23 23:22, Goetz Golla wrote:
>> * Does MIT Kerberos support PKINIT with Elliptic Curves as described
>> in RFC 5349 ?
>
>A P-384 EC client certificate works in my tests, with either krb5-1.17
>or the current code, as long as the KDC is also running MIT krb5.
We got burnt a while ago
>in our organisation we are successfully using PKINIT with RSA 2048
>client certificates for many years. We are now trying to move to ECC
>certificates with the curve secp384r1.
>
>All attempts have been unsuccessful yet.
My reading of the code (I am using a newer version of MIT Kerberos than
I am DEFINITELY not an expert in S4U* nor Windows APIs, but I have
looked into this a BIT and I can give you some thoughts.
>Now we wants to switch from Windows AD to MIT KDC. Currently windows
>can be authenticated by MIT KDC without any problem but Windows API
>LSALogonUser() in our application
>I’m working on integrating kerberos authentication to my c++
>app. I’m developing on macos where the default credential cache is
>of type API:. Initializing a credential cache with KCM: results in
>a deprecation warning asking to use API: instead. My problem in the
>c++ app is that I cannot find
>Uh... If someone was able to swing that then you should be able to
>swing use of MD5 for non-cryptographic purposes where a 20 year old RFC
>requires it. But, I know, I know, never mind.
You are assuming someone is looking at all of the STIGs and they're all
logically consistent with each
>> Right, part of the problem there is that people want to "use Kerberos
>> with ssh", and they don't understand the difference between gssapi-
>> with-mic
>> and gss-keyex.
>
>Aren't you supposed to use CAC or PIV cards?
Well, I hate to use the "Air Bud" loophole, but the rules as I
understand
>On Thu, Oct 26, 2023 at 05:57:37PM -0400, Ken Hornstein via Kerberos wrote:
>> You know that. I know that. But remember: "if you're explaining,
>> you're losing". When asked I can honestly say, "Kerberos is not
>> a PKI" and that's good enough, but I c
>> Unfortunately, ANOTHER one of the "fun" rules I live under is, "Thou
>> shall have no other PKI than the DoD PKI". And as much as I can
>> legitimately argue for many of the unusual things that I do, I can't get
>> away with that one; [...]
>
>A CA that issues short-lived certificates (for
>So what can you do? Well, you could build an online kerberized CA that
>vends short-lived OpenSSH-style certificates, then use that for SSH.
>
>Perhaps you'll find that easier to do than to send a PR for hard-coding
>mechanism OID->name mappings, and even if not, you may find it better
>for the
>> As a side note, my impression is that gss-keyex has fallen out of favor,
>> and at least for us part of the problem is the unfortunate decision
>> to use MD5 in that protocol. You and I both know that the use of MD5
>> in there isn't security related, but if you live in a FIPS world
>> then
>> Ever hear the political adage, "If you're explaining yourself, you're
>> losing"?. The same adage applies when talking to security people,
>> especially the non-technical ones. The common gss-keyex code out there
>> calls the OpenSSL MD5 function at runtime, and some of the distributions
>>
>Yeah; IIRC that was to allow cases where the initiator would send the first
>context token in the same packet/message with early data, such as a MIC
>binding the exchange to some channel. In retrospect, perhaps it has caused
>more trouble than it was worth. We didn't use this in RFC 4462
>Yeah; IIRC that was to allow cases where the initiator would send the first
>context token in the same packet/message with early data, such as a MIC
>binding the exchange to some channel. In retrospect, perhaps it has caused
>more trouble than it was worth. We didn't use this in RFC 4462
>Until then you don't know because GSS doesn't know if some MIC/Wrap
>token it's consuming was made in response to an earlier MIC/Wrap/AP-REP
>token sent by the acceptor application to the initiator. Also, in
>practice no app that makes use of PROT_READY before GSS_S_COMPLETE on
>the initiator
>Whether the initiator can generate per-message tokens before receiving
>the subkey depends on whether the mechanism returned the prot_ready
>state (RFC 2743 section 1.2.7) to the caller after generating the
>initiator token. RFC 4121 does not mention prot_ready; I couldn't say
>whether
To give some background, we are required to do security scanning of our
systems using Tenable's security scanner product (which is variously
known as Nessus, Tenable.sc, or ACAS if you're in the DoD; I'm aware
that these all aren't the same thing but in practice they all seemed to
be lumped
>In a similar vien to my previous communication, I've found myself trying
>to update my principles from 3DES to AES. While this was successful for
>the most part, one of the issues that evades me is the correct way to
>rekey kadmin/history, as it seems the usual process doesn't work.
>Please
>I am wondering if it is reasonable to request the MIT library to
>support PAC decoding (possibly in form of Named Attributes) so that the
>information there could be used in calling application, I.e.:
>
>https://github.com/gssapi/mod_auth_gssapi/issues/288#issuecomment-1690541858
>
>Is something
>Anonymous PKINIT works fine but requires certs to be distributed. Unless
>you're prepared to update every machine in the world every year, you
>pretty much have to use a cert that goes back to a commercial CA.
At least for us, we already did that hard work and have PKINIT already
working within
>I worked through a bunch of this for pam-krb5 back in the day and made it
>support a set of reasonable things, including anonymous PKINIT to
>establish the FAST armor. People who are working in this area may find
>its source code useful to look at, although I think there have been
>improvements
>The docs that I referenced still made it seem that the anchor config
>was somewhat optional for anonymous auth.
>
>..but maybe I wasn't reading those lines with the proper mindset or context.
Looking at that, I can see why you would come to that conclusion. It
was obvious to ME that you needed
>Since I am currently only interested in anonymous auth, I thought I
>could skip that directive. But alas:
Right, so, here's where my limited knowledge of FAST comes into play.
As I understand it, you need to be able to use a trusted key to
authenticate with the KDC to to create the FAST
>On 4/25/23 20:01, Ken Hornstein via Kerberos wrote:
>> First, there's about 500x ways for PKINIT to go wrong, and when it does
>> go wrong 99% of the time you fall back to a password so it's hard to
>> figure out exactly what failed.
>
>Assuming the kadmin client and KD
>Making progress... but still need some pointers.
>[...]
Remember when I said setting up PKINIT is about as much fun as getting a
punch in the face from John Cena? Well, you're about to discover what
I mean by that.
First, there's about 500x ways for PKINIT to go wrong, and when it does
go
>make it look like you can put the secret directly into the
>configuration file. There seems to be a little bit of disconnect
>between those two parts of the docs. I just wanted to point it out if
>it is helpful.
It looks like (according to the source code) it has to have that as
a filename.
>It *looks* like, in order to check basically fakes this out with a
>krb5.conf that only includes a single KDC (the one being tested).
>
>Is that really the best way to go about it?
>
>Can neither mit kinit nor the heimdal one supplied with BSD systems by
>default, not just be forced to a single
>First problem: I have a second principal, jason/admin, for use with
>kadmin. I've generated a certificate that can authenticate. However, now
>that I have two certificates (one for jason and another for
>jason/admin), it isn't clear how to configure the client to offer the
>correct
>I have to apologize to everyone here and thank you and Sam for your
>feedback: the tone of my original message was an edge to sharp. I should
>have had my frustration under control that my asking a lowly question
>gets no reply on a mailing list with evidently a kiloton of critically
>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).
Dude, I can't speak for anyone else, but I didn't know the answer (and
it involved
>As an alternative to the krb5 api, stick in the krb5 mechanism oid.
>You can definitively design your protocol and implementation for a
>single round trip by doing that.
>You can have more code in common with applications that do support
>multi-round-trip negotiations, while still getting your
>If you're using SPNEGO then you don't have to concern yourself with
>negotiation. If you're implementing SSHv2 or SASL it's another story,
>though not much more complicated because you're doing negotiation at a
>layer that already does it and all you have to do is maybe pick a GSS
>mechanism.
>
>I guess if I’m on a tear saying forbidden things, sometimes identity is all
>you need, you don’t want all the samples to encrypt everything, because
>that makes it look like you have to, which you don’t? It is use-case
>dependent, and krb5 is great because it is granular enough to let
>I have said this before on the list and it’s not a very popular thing to
>say, but I program to the krb5 public API, and it is a nice and clean and
>performant and simple and portable and flexible API, and GSSAPI looks like
>none of those things, it looks like a mess to use (just from looking at
>The profile library has the concept of marking a section or subsection
>as "final", preventing further amendments to that section. But that
>concept does not apply to individual relations (although it was
>erroneously documented as applying to them prior to 1.17.1).
When I looked at the
>On 9/30/22 16:06, Machin, Glenn Douglas via Kerberos wrote:
>> Can someone tell me if a TGT containing an authentication indicator will
>> work over to a service principal in another realm which has a cross realm
>> trust relationship?
>
>Authentication indicators are currently only accepted
>> This is one of our worst error messages (see
>> https://krbdev.mit.edu/rt/Ticket/Display.html?id=8247 ).
>
>Yeah, no kidding. I actually looked at the source a while ago to try and
>figure out what was happening, but no luck; the location where the error
>message is printed has absolutely no
>I am a bit surprised that the cnames in the krb5.conf file were the
>problem. I would like to use a common krb5.conf file everywhere
>deployed by our configuration management processes. I guess one what
>would be to create principals for the cnames. Seems a bit unclean. Or
>just have a unique
>Thanks Greg. I should have remembered that. It exposed the fact
>that the kiprop/ principal for the host was missing. I created the
>principal and added it to /etc/krb5.keytab. This moved the error, but
>I am still getting failures to replicate. Here is the debug log:
Did you, in fact,
>gotcha, thank you very much for all the help.
>I guess just out of curiosity:
>- for windows: there are other tools such as heimdall and microsoft
>kerberos. with those I don't know if you ever played around with them or
>know if they support smartcard and pin authentication to get a ticket
>for more information on this"
>- People I work with have adapted the stock MIT Kerberos PKINIT plugin
> to work on Windows.
>
>Do you have any sort of documentation that you can point me to on how to
>make this work with windows. And also Mac as, we also have Mac users.
Unfortunately, no (at
>i was wondering if the question listed in the link below was ever answered
>and if not, i was hoping you could provide please.
>https://mailman.mit.edu/pipermail/kerberos/2010-September/016423.html
I can provide a quick summary:
- Current stock MIT Kerberos for Windows does not support pkinit
>Yes. That is the "for-purpose" mechanism that I alluded to earlier
>which is why I posited that if smtpd was clearing the environment it
>was doing so in violation of the specific mechanism that was supposed
>to make this all work.
Oh, hm. I might be reading the code wrong, but it looks like
>> Is it possible Postfix is clearing out the environment at startup?
>
>As anything, I suppose it is possible. It would be doing so in
>violation of exactly the purpose of the mechanism that is being used to
>set the environment though.
Hm. From postconf(5):
import_environment (default: see
>I am trying to debug why having KRB5_KTNAME set in the environment of a
>process is not actually making that process use that keytab file but
>instead is using the default /etc/krb5.keytab.
>
>The process is Postfix's SMTP deamon (smtpd).
>[...]
>Any thoughts/ideas?
Is it possible Postfix is
77 matches
Mail list logo
