RE: Question about Windows S4U support
Thanks for the reply. One strange thing is that when Windows is using AD
domain, sname doesn't have this format: host/win11client.mylab.com but
win11client$. I have no idea what makes Windows have this difference.
For PAC validation error, I also can't get more detailed information from
Windows logging what causes the validation failure.
-Original Message-
From: Greg Hudson
Sent: Friday, November 10, 2023 6:44 AM
To: JianJun Li ; kerberos@mit.edu
Subject: Re: Question about Windows S4U support
EXTERNAL EMAIL
On 11/8/23 09:23, JianJun Li wrote:
> In fact, principle "host/win11client.mylab@mylab.com" exists. By
> Wireshark I can see Windows sends "host/win11client.mylab@mylab.com" as
> sname, KDC converts the sname to host\/win11client.mylab@mylab.com.
> I have a look at the code but find no parameters or setting can change this
> behavior.
I can give a detailed but ultimately not very helpful answer:
As Ken explained in part, the wire representation of principals in Kerberos is
the ASN.1 DER encoding of a name-type and a sequence of strings. Microsoft
created a name type NT-ENTERPRISE which puts an email-address-like string in
the first string element. When you see "host\/..." in your log, that is the
MIT krb5 library's string representation of an NT-ENTERPRISE principal.
RFC 6806 section 5 describes this name type as conveying alias names, to be
used in the client field of an AS-REQ to a KDC with a directory service that
can map email addresses to canonical principal names.
However, Microsoft's implementation now also uses this type in server names
during under some circumstances, including some S4U operations.
[MS-KILE] 3.3.5.1.1 defines semantics for server name lookup of NT-ENTERPRISE
principals (in terms of underlying facilities specific to Active Directory);
[MS-SFU] unfortunately does not seem to say precisely when they are used. I
had thought they were only used for cross-realm S4U2Self operations where it is
necessary to communicate the requesting service's realm to the client realm,
but based on your log it sounds like they are also used for same-realm S4U2Self
requests made by Windows clients.
Although MIT krb5 has S4U2Self and S4U2Proxy logic in the KDC code, it does not
implement NT-ENTERPRISE lookup. The translation from NT-ENTERPRISE
{"host/win11client.mylab@mylab.com"} to NT-PRINCIPAL {"host",
"win11client.mylab.com"} currently has to be done within the KDB layer, either
by using an encompassing piece of software with a KDB module (such as Samba),
or by setting up an explicit alias in the LDAP KDB module (the BDB and LMDB
modules do not support aliases). I believe the situation could be improved by
performing this translation within the KDC for TGS service lookups, but that
improvement, although simple in concept, would require careful testing.
> The digitally signed Privilege Attribute Certificate (PAC) that contains the
> authorization information for client user in realm MYLAB.COM could not be
> validated.
> This error is usually caused by domain trust failures; Contact your system
> administrator.
I don't know exactly what is causing this error on the Windows side, especially
if it only happens some of the time. I will note that when used with any of
the built-in KDB modules (BDB, LMDB, or LDAP), MIT krb5's KDC includes a
minimal PAC with no SID or group information.
Encompassing software such as Samba is required to supply a complete PAC within
issued tickets. This limitation may be unrelated to the error given that the
error does not always occur.
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support:
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
This communication and any attachments may contain confidential information of
Rocket Software, Inc. All unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please notify Rocket
Software immediately and destroy all copies of this communication. Thank you.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about Windows S4U support
On 11/8/23 09:23, JianJun Li wrote:
In fact, principle "host/win11client.mylab@mylab.com" exists. By Wireshark I can
see Windows sends "host/win11client.mylab@mylab.com" as sname, KDC converts the
sname to host\/win11client.mylab@mylab.com.
I have a look at the code but find no parameters or setting can change this
behavior.
I can give a detailed but ultimately not very helpful answer:
As Ken explained in part, the wire representation of principals in
Kerberos is the ASN.1 DER encoding of a name-type and a sequence of
strings. Microsoft created a name type NT-ENTERPRISE which puts an
email-address-like string in the first string element. When you see
"host\/..." in your log, that is the MIT krb5 library's string
representation of an NT-ENTERPRISE principal.
RFC 6806 section 5 describes this name type as conveying alias names, to
be used in the client field of an AS-REQ to a KDC with a directory
service that can map email addresses to canonical principal names.
However, Microsoft's implementation now also uses this type in server
names during under some circumstances, including some S4U operations.
[MS-KILE] 3.3.5.1.1 defines semantics for server name lookup of
NT-ENTERPRISE principals (in terms of underlying facilities specific to
Active Directory); [MS-SFU] unfortunately does not seem to say precisely
when they are used. I had thought they were only used for cross-realm
S4U2Self operations where it is necessary to communicate the requesting
service's realm to the client realm, but based on your log it sounds
like they are also used for same-realm S4U2Self requests made by Windows
clients.
Although MIT krb5 has S4U2Self and S4U2Proxy logic in the KDC code, it
does not implement NT-ENTERPRISE lookup. The translation from
NT-ENTERPRISE {"host/win11client.mylab@mylab.com"} to NT-PRINCIPAL
{"host", "win11client.mylab.com"} currently has to be done within the
KDB layer, either by using an encompassing piece of software with a KDB
module (such as Samba), or by setting up an explicit alias in the LDAP
KDB module (the BDB and LMDB modules do not support aliases). I believe
the situation could be improved by performing this translation within
the KDC for TGS service lookups, but that improvement, although simple
in concept, would require careful testing.
The digitally signed Privilege Attribute Certificate (PAC) that contains the
authorization information for client user in realm MYLAB.COM could not be
validated.
This error is usually caused by domain trust failures; Contact your system
administrator.
I don't know exactly what is causing this error on the Windows side,
especially if it only happens some of the time. I will note that when
used with any of the built-in KDB modules (BDB, LMDB, or LDAP), MIT
krb5's KDC includes a minimal PAC with no SID or group information.
Encompassing software such as Samba is required to supply a complete PAC
within issued tickets. This limitation may be unrelated to the error
given that the error does not always occur.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Question about Windows S4U support
Thank you Ken for the valuable feedback.
I'm using latest version V1.21 with its default backend DB. After the test, if
all works, I will try the combination MIT KDC + OpenLDAP then.
There are not so much available materials I can refer to like my case.
Sometimes I really doubt Windows S4U API may be not completely compatible with
MIT KDC, but based on current investigation, I still can't draw any
conclusions. That's why I post comments here.
Regards
Jianjun Li
-Original Message-
From: Ken Hornstein
Sent: Thursday, November 9, 2023 3:17 AM
To: JianJun Li
Cc: kerberos@mit.edu
Subject: Re: Question about Windows S4U support
EXTERNAL EMAIL
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 fails.
It should be noted that up front that there are some caveats to MIT Kerberos
S4U support. The specific one that I am aware of is that you cannot use the
db2 database (the default) as the KDC backend; you need to use the LDAP KDB
module and configure a special attribute called "krbAllowedToDelegateTo" to
configure a service principal to permit S4U2Self. I am not sure this is
relevant to this discussion though.
>Nov 03 14:01:40 niuniu krb5kdc[13724](info): TGS_REQ (5 etypes
>{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
>DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24),
>UNSUPPORTED:(-135)}) 192.168.0.5: LOOKING_UP_SERVER: authtime 0,
>host/win11client.mylab@mylab.com<mailto:host/win11client.mylab.com@
>MYLAB.COM> for host\/win11client.mylab@mylab.com, Server not found
>in Kerberos database
It's important to understand that INTERALLY Kerberos principals are represented
as a sequence of one or more strings and a realm. So while you may see a
principal in the form of "host/win11cli...@mylab.com"
that's just the user representation. Really that's encoded on the wire as the
strings "host" and "win11client", and the realm MYLAB.COM. If MIT Kerberos is
displaying that as "host\/win11cli...@mylab.com", then that means it's getting
ONE string for that principal that contains "host/win11client" (the '/' is the
traditional separator for strings in a Kerberos principal). I have no idea why
that is happening, but that suggests to me that there is some problem on the
client side.
--Ken
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support:
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
This communication and any attachments may contain confidential information of
Rocket Software, Inc. All unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please notify Rocket
Software immediately and destroy all copies of this communication. Thank you.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about Windows S4U support
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 fails.
It should be noted that up front that there are some caveats to MIT
Kerberos S4U support. The specific one that I am aware of is that
you cannot use the db2 database (the default) as the KDC backend;
you need to use the LDAP KDB module and configure a special attribute
called "krbAllowedToDelegateTo" to configure a service principal to
permit S4U2Self. I am not sure this is relevant to this discussion
though.
>Nov 03 14:01:40 niuniu krb5kdc[13724](info): TGS_REQ (5 etypes
>{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
>DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24),
>UNSUPPORTED:(-135)}) 192.168.0.5: LOOKING_UP_SERVER: authtime 0,
>host/win11client.mylab@mylab.com<mailto:host/win11client.mylab@mylab.com>
> for host\/win11client.mylab@mylab.com, Server not found in Kerberos
>database
It's important to understand that INTERALLY Kerberos principals are
represented as a sequence of one or more strings and a realm. So while
you may see a principal in the form of "host/win11cli...@mylab.com"
that's just the user representation. Really that's encoded on the wire
as the strings "host" and "win11client", and the realm MYLAB.COM. If
MIT Kerberos is displaying that as "host\/win11cli...@mylab.com", then that
means it's getting ONE string for that principal that contains
"host/win11client" (the '/' is the traditional separator for strings
in a Kerberos principal). I have no idea why that is happening, but
that suggests to me that there is some problem on the client side.
--Ken
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Question about Windows S4U support
Hi everyone,
We have an application with Windows client + AD domain, for S4USelf, it works
well.
In our application, it calls LSALogonUser() to impersonate a user which will
use S4USelf by setting up Windows structure KERB_S4U_LOGON.
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 fails.
Problem 1:
When LSALogonUser() is called, it has following error:
Nov 03 14:01:40 niuniu krb5kdc[13724](info): TGS_REQ (5 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24),
UNSUPPORTED:(-135)}) 192.168.0.5: LOOKING_UP_SERVER: authtime 0,
host/win11client.mylab@mylab.com<mailto:host/win11client.mylab@mylab.com>
for host\/win11client.mylab@mylab.com, Server not found in Kerberos
database
In fact, principle
"host/win11client.mylab@mylab.com<mailto:host/win11client.mylab@mylab.com>"
exists. By Wireshark I can see Windows sends
"host/win11client.mylab@mylab.com<mailto:host/win11client.mylab@mylab.com>"
as sname, KDC converts the sname to host\/win11client.mylab@mylab.com.
I have a look at the code but find no parameters or setting can change this
behavior.
Problem 2:
Sometimes, AS-REQ and TGS-REQ are all ok in MIT KDC but on Windows, it reports
this error in Windows Event Viewer after call LSALogonUser():
The digitally signed Privilege Attribute Certificate (PAC) that contains the
authorization information for client user in realm MYLAB.COM could not be
validated.
This error is usually caused by domain trust failures; Contact your system
administrator.
I also test "kvno -U user" on the same windows machine, and it works.
>From MIT Kerberos document, I can see S4U can be supported. My question is
>that for S4U, does MIT KDC have interoperability with Windows API? Any
>feedback will be greatly appreciated.
I'm a newbie in Kerberos, thanks for your help!
Regards
Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ?
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support:
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
This communication and any attachments may contain confidential information of
Rocket Software, Inc. All unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please notify Rocket
Software immediately and destroy all copies of this communication. Thank you.
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")
>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 >condensed knowledge in the subject matter. Of course nobody owes me >nothing here - sorry. Thank you; I for one appreciate your apology. >> Judging by the thread you posted, it sure seems like the problem >> was specific to the Postgresql implementation on Windows so it's not >> surprising nobody here would be an expert on that. > >The question was in fact not specific to Postgresql. It was pretty much >a generic "I can't get my windows client to authenticate via >SSPI/AD/Kerberos". It was just that it was psql that showed the symptoms >and that I as a newbie in the subject matter was caught up in that >oekosystem. However the problem is/was a generic client -> >SSPI/AD/Kerberos one. Wlll ... I was curious and I re-read that thread, and it sure seems like the problem was kind of Postgres-specific, in that: Postgres on Windows is compiled with both SSPI and GSSAPI support, you were trying to use the GSSAPI support and it didn't work (but it wasn't clear that you had even launched or configured MIT KfW at all), and it worked fine when you configured Postgres it to use SSPI support. --Ken 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")
On 10.03.23 19:25, Ken Hornstein via Kerberos wrote: 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 Windows, which I am not that familiar with), _and_ my day job does not pay me to support people on the MIT Kerberos mailing list. That's not to say I'm opposed to helping people, but if I don't know the answer I'm not going to chime in with a "Sorry, I have no idea" kind of answer because that doesn't help anyone. 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 condensed knowledge in the subject matter. Of course nobody owes me nothing here - sorry. Judging by the thread you posted, it sure seems like the problem was specific to the Postgresql implementation on Windows so it's not surprising nobody here would be an expert on that. The question was in fact not specific to Postgresql. It was pretty much a generic "I can't get my windows client to authenticate via SSPI/AD/Kerberos". It was just that it was psql that showed the symptoms and that I as a newbie in the subject matter was caught up in that oekosystem. However the problem is/was a generic client -> SSPI/AD/Kerberos one. Anyway, thanks a lot for pointing out to me what I should do better next time!!! Greetings and thanks to all! *t 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")
On 10.03.23 18:12, Sam Hartman wrote: "Tomas" == Tomas Pospisek writes: Tomas> Also, since I got precisely zilch feedback here while there Tomas> were other postings here I'm under the impression that this Tomas> is a mailing list with *no* user support (but instead a Tomas> development list or similar). If that's the case, then it Tomas> would be certainly helpful for other similar poor mislead Tomas> souls like me to have that characteristic of the mailing list Tomas> documented on it's page: Tomas> http://web.mit.edu/kerberos/new/mail-lists.html ... I've been reading this list since the mid 90's, and I believe your post was on-topic. For myself, I didn't happen to know the answer off the top of my head, and your post came in at a point where I didn't have any spare cycles. I'm also a lot less involved in Kerberos than I used to be. Sorry for the delay and thanks a lot for your reply Sam. See also my followup to Ken Hornstein's answer. *t 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: kerberos client on windows not being able to access credentials cache ("Internal credentials cache error")
>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 Windows, which I am not that familiar with), _and_ my day job does not pay me to support people on the MIT Kerberos mailing list. That's not to say I'm opposed to helping people, but if I don't know the answer I'm not going to chime in with a "Sorry, I have no idea" kind of answer because that doesn't help anyone. Judging by the thread you posted, it sure seems like the problem was specific to the Postgresql implementation on Windows so it's not surprising nobody here would be an expert on that. --Ken 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")
> "Tomas" == Tomas Pospisek writes: Tomas> Also, since I got precisely zilch feedback here while there Tomas> were other postings here I'm under the impression that this Tomas> is a mailing list with *no* user support (but instead a Tomas> development list or similar). If that's the case, then it Tomas> would be certainly helpful for other similar poor mislead Tomas> souls like me to have that characteristic of the mailing list Tomas> documented on it's page: Tomas> http://web.mit.edu/kerberos/new/mail-lists.html ... I've been reading this list since the mid 90's, and I believe your post was on-topic. For myself, I didn't happen to know the answer off the top of my head, and your post came in at a point where I didn't have any spare cycles. I'm also a lot less involved in Kerberos than I used to be. 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")
Hello, 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. 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 ... Thanks, *t On 20.02.23 14:11, Tomas Pospisek wrote: Hello all, tldr: D:\>C:\OSGeo4W\bin\psql.exe service=the_db psql: error: connection to server at "dbserver.example.lan (192.168.4.104), port 5432 failed: could not initiate GSSAPI security context: No credentials were supplied, or the credentials were unavailable or inaccessible: Internal credentials cache error Goal I want to have my Postgresql clients (in this case psql.exe) on Windows to authenticate against Active Directory. Steps taken so far == Linux client -> Active Directory -> Linux server works -- I was able to get psql on Linux to authenticate against Active Directory and with the service ticket that it got from Active Directory to authenticate to the Postgresql service and server. Windows client -> Active Directory does not work ---- I do know that psql.exe (on Windows) is linked and is using GSS to do Kerberos authentication. A psql.exe that is not linked against GSS will tell me: "gssencmode value "require" invalid when GSSAPI support is not compiled in" A psql.exe that is linked against GSS will not tell me that. I'm evidently now using the latter - a psql.exe that is linked against GSS. -> So I know that the psql.exe that I'm using is linked against GSS. Also, in the Windows shell I can issue a klist, and I see the Ticket Granting Ticket and I see various service tickets (mainly to mount CIFS shares). Also on Windows shell I can issue a klist get postgres/dbserver.example@example.lan and I see the ticket listed when I issue klist. -> So I know that getting the service ticket on the Windows client does indeed work. When using psql.exe without setting `gssencmode = require` I am able to authenticate with username/password and connect to the Postgresql service on the DB server just fine. -> So I know that there is no problem with psql.exe wrt to connecting to the Postgresql server and there is no problem with authentication per se. I tried to trace psql.exe with the "Process Monitor" tool. I see that (for whatever reason), psql.exe will open a TCP connection to the Postgresql server. But it will *NOT* open a connection to the Active Directory server. Maybe it *shoud* connect to a local (that is on the local host) authentication/active directory service, but I do not know enough Windows to know how I would see that in the "Process Monitor" trace. I can see that psql.exe is accessing the Windows Registry and that it's accessing various DLLs, among others the kerberos library, and various config files, such as the krb5.conf file, but I can not see it accessing a keytab. Again I do not know *exactly* how Active Directory/Kerberos access works on Windows, but I *suspect* that the protocol on a Windows client is *not* using keytab file. I do see that `psql.exe` is trying to access a `ccapiserver.exe` file, that is not there. Question: is a `ccapiserver.exe` executable required in order to be able to access tickets from a Kerberos client on a Windows client? Other question: is the error "Internal credentials cache error" the root cause of psql.exe not being able to authenticate against Active Directory (I am supposing that the error "Internal credentials cache error" refers to the kerberos client not being able to access the *existing* tickets. But in "theory" psql.exe could try getting a ticket *without* accessing the existing tickets? So it wouldn't have to forcibly fail there?). And another question: is there any way to make GSS more talkative? At this moment all that I can get as logs is the above "computer says no". I was able to set the kerberos log to a local file, but that just tells me that the client now wants to do authentication and that's that. So that's as far as I got and I'm a bit at the end of my wisdom and a would very, very much appreciate: * help on how to proceed from here * pointers to how configure krb5.conf-wise a given Windows executable that links against GSS so that it can authentica
kerberos client on windows not being able to access credentials cache ("Internal credentials cache error")
Hello all, tldr: D:\>C:\OSGeo4W\bin\psql.exe service=the_db psql: error: connection to server at "dbserver.example.lan (192.168.4.104), port 5432 failed: could not initiate GSSAPI security context: No credentials were supplied, or the credentials were unavailable or inaccessible: Internal credentials cache error Goal I want to have my Postgresql clients (in this case psql.exe) on Windows to authenticate against Active Directory. Steps taken so far == Linux client -> Active Directory -> Linux server works -- I was able to get psql on Linux to authenticate against Active Directory and with the service ticket that it got from Active Directory to authenticate to the Postgresql service and server. Windows client -> Active Directory does not work I do know that psql.exe (on Windows) is linked and is using GSS to do Kerberos authentication. A psql.exe that is not linked against GSS will tell me: "gssencmode value "require" invalid when GSSAPI support is not compiled in" A psql.exe that is linked against GSS will not tell me that. I'm evidently now using the latter - a psql.exe that is linked against GSS. -> So I know that the psql.exe that I'm using is linked against GSS. Also, in the Windows shell I can issue a klist, and I see the Ticket Granting Ticket and I see various service tickets (mainly to mount CIFS shares). Also on Windows shell I can issue a klist get postgres/dbserver.example@example.lan and I see the ticket listed when I issue klist. -> So I know that getting the service ticket on the Windows client does indeed work. When using psql.exe without setting `gssencmode = require` I am able to authenticate with username/password and connect to the Postgresql service on the DB server just fine. -> So I know that there is no problem with psql.exe wrt to connecting to the Postgresql server and there is no problem with authentication per se. I tried to trace psql.exe with the "Process Monitor" tool. I see that (for whatever reason), psql.exe will open a TCP connection to the Postgresql server. But it will *NOT* open a connection to the Active Directory server. Maybe it *shoud* connect to a local (that is on the local host) authentication/active directory service, but I do not know enough Windows to know how I would see that in the "Process Monitor" trace. I can see that psql.exe is accessing the Windows Registry and that it's accessing various DLLs, among others the kerberos library, and various config files, such as the krb5.conf file, but I can not see it accessing a keytab. Again I do not know *exactly* how Active Directory/Kerberos access works on Windows, but I *suspect* that the protocol on a Windows client is *not* using keytab file. I do see that `psql.exe` is trying to access a `ccapiserver.exe` file, that is not there. Question: is a `ccapiserver.exe` executable required in order to be able to access tickets from a Kerberos client on a Windows client? Other question: is the error "Internal credentials cache error" the root cause of psql.exe not being able to authenticate against Active Directory (I am supposing that the error "Internal credentials cache error" refers to the kerberos client not being able to access the *existing* tickets. But in "theory" psql.exe could try getting a ticket *without* accessing the existing tickets? So it wouldn't have to forcibly fail there?). And another question: is there any way to make GSS more talkative? At this moment all that I can get as logs is the above "computer says no". I was able to set the kerberos log to a local file, but that just tells me that the client now wants to do authentication and that's that. So that's as far as I got and I'm a bit at the end of my wisdom and a would very, very much appreciate: * help on how to proceed from here * pointers to how configure krb5.conf-wise a given Windows executable that links against GSS so that it can authenticate against active directory * any help and pointer or debugging help * has anybody been able to authenticate from Windows against Active Directory and how did you do that respectively how did you set it up? Any help would be very, very much appreciated, thank you. *t Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: windows and smartcards
>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 >manually. >manually meaning, get a ticket for a specified account with the use of >kinit or similar tools.. Here's my limited, imperfect understanding of the situation. - My understanding is that the Kerberos implementation supplied by Microsoft does implement PKINIT and works with smartcards. But I am not sure if you can use it OUTSIDE of an Active Directory domain. - It seems that Heimdal _does_ implement PKINIT. But it's not clear to me that they support using PKCS#11 to sign the PKINIT request, which is the piece you need to make it work with Smartcards. I mean, I see there is SOME PKCS#11 support, I just didn't see any calls to something like C_SignInit. It's very possible I missed it. You're going to have to investigate that on your own. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: windows and smartcards
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 manually. manually meaning, get a ticket for a specified account with the use of kinit or similar tools.. Prabin On Wed, May 4, 2022 at 10:00 PM Ken Hornstein wrote: > >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 least, not on Windows). > > We compile our own Kerberos kit for Windows, which have the changes in > it to build the PKINIT plugin. Actually, I believe it's worse than > that; from memory I believe we have a separate PKINIT plugin directory. > And ... the build environment is a huge mess there. I don't recall that > the code changes are large (I didn't do them), but you do need to source > a windows-compatible regular expression library. One of my long term > goals is to get us using as much stock MIT code as possible, but I never > did work out getting our changes to PKINIT to make it functional on Windows > into stock MIT Kerberos. So, I can't really help you there. > > >Currently, my main focus is on windows machines, so, the steps I have done > >to try to authenticate with a smartcard: > >1. install MIT kerberos > >2. Install opensc-pkcs11 > >3. use the following commands in the hope that it will use smartcard: > >kinit -X x509_user_identity=PKCS11:path_to_PKCS11.dill > > Right, I think you'll have more success with this on MacOS X. The code > for Windows simply doesn't exist, at least in vanilla MIT Kerberos. There > are a lot of pieces you need to make PKINIT work, so I'd start with a > platform where it at least is known to work. > > --Ken > -- Thank you, Prabin Tamang Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: windows and smartcards
Hi, 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. Currently, my main focus is on windows machines, so, the steps I have done to try to authenticate with a smartcard: 1. install MIT kerberos 2. Install opensc-pkcs11 3. use the following commands in the hope that it will use smartcard: kinit -X x509_user_identity=PKCS11:path_to_PKCS11.dill but I have not been successful. again, I am continuing this discussion because you mentioned that "people have made it work with windows with the use of pkinit plugin". and finally, I would like to say thank you very much for replying as this was very helpful information. Best, Prabin On Wed, May 4, 2022 at 7:40 PM Ken Hornstein wrote: > >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 (that's > what you need to use Smartcards). > > - People I work with have adapted the stock MIT Kerberos PKINIT plugin > to work on Windows. > > - We've talked with MIT about contributing this code back; it proceeds > in fits and starts. The last hold-up was getting a C language regular > expression library with an acceptable license for MIT (I didn't > think this would be a problem, but it turns out that it is). We use > a PCRE library for our distribution but that has it's own issues. > Unfortunately the developers on that project lost their contract and > there aren't currently resources to push that forward into something > that MIT would find acceptable. > > - To answer the specific question in that email message: stock MIT Kerberos > works fine with PKINIT under OS X. If you want to use it with > Smartcards, you need a compatible PKCS#11 library. If you are using > the native smartcard support on OS X (which at the moment only > supports PIV cards as far as I know), you can use Keychain-PKCS11. > For other smartcards you could probably use OpenSC which provides > a PKCS#11 library and support for smartcards that OS X does not > support natively. In the interests of full disclosure: I wrote > Keychain-PKCS11 so I am obviously biased toward it. > > --Ken > -- Thank you, Prabin Tamang Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: windows and smartcards
>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 least, not on Windows). We compile our own Kerberos kit for Windows, which have the changes in it to build the PKINIT plugin. Actually, I believe it's worse than that; from memory I believe we have a separate PKINIT plugin directory. And ... the build environment is a huge mess there. I don't recall that the code changes are large (I didn't do them), but you do need to source a windows-compatible regular expression library. One of my long term goals is to get us using as much stock MIT code as possible, but I never did work out getting our changes to PKINIT to make it functional on Windows into stock MIT Kerberos. So, I can't really help you there. >Currently, my main focus is on windows machines, so, the steps I have done >to try to authenticate with a smartcard: >1. install MIT kerberos >2. Install opensc-pkcs11 >3. use the following commands in the hope that it will use smartcard: >kinit -X x509_user_identity=PKCS11:path_to_PKCS11.dill Right, I think you'll have more success with this on MacOS X. The code for Windows simply doesn't exist, at least in vanilla MIT Kerberos. There are a lot of pieces you need to make PKINIT work, so I'd start with a platform where it at least is known to work. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: windows and smartcards
>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 (that's what you need to use Smartcards). - People I work with have adapted the stock MIT Kerberos PKINIT plugin to work on Windows. - We've talked with MIT about contributing this code back; it proceeds in fits and starts. The last hold-up was getting a C language regular expression library with an acceptable license for MIT (I didn't think this would be a problem, but it turns out that it is). We use a PCRE library for our distribution but that has it's own issues. Unfortunately the developers on that project lost their contract and there aren't currently resources to push that forward into something that MIT would find acceptable. - To answer the specific question in that email message: stock MIT Kerberos works fine with PKINIT under OS X. If you want to use it with Smartcards, you need a compatible PKCS#11 library. If you are using the native smartcard support on OS X (which at the moment only supports PIV cards as far as I know), you can use Keychain-PKCS11. For other smartcards you could probably use OpenSC which provides a PKCS#11 library and support for smartcards that OS X does not support natively. In the interests of full disclosure: I wrote Keychain-PKCS11 so I am obviously biased toward it. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
windows and smartcards
HI, 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 -- Thank you, Prabin Tamang Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Cross compilation problems targeting mac and windows
Dear list, I'm trying to compile krb5 for the Julia [BinaryBuilder]( https://github.com/JuliaPackaging/BinaryBuilder.jl), which depends on cross compilation. The tests are done with version Kerberos 1.19.3, which is latest release. When running configure for cross compilation I get an error. Eg: ``` krb5-1.19.3/src$ ./configure --build=x86_64-linux-gnu --host=aarch64-linux-musl checking for constructor/destructor attribute support... configure: error: Cannot test for constructor/destructor support when cross compiling ``` Searching the internet found some variables to set to make the configure run through: ``' krb5-1.19.3/src$ ac_cv_func_regcomp=yes ac_cv_printf_positional=yes krb5_cv_attr_constructor_destructor=yes,yes ./configure --build=x86_64-linux-gnu --host=aarch64-linux-musl ``` With this I can build for linux and bsd, but it fails to build for mac and windows. I have 2 questions: 1. Can I trust the builds coming out of the above configuration? 2. What is needed to make cross compilation to mac and windows work? Hope you can help me. Below is the last output when the mac build fails: [14:57:20] cc -DSHARED -DHAVE_CONFIG_H -I../../../include -I../../../include -I./ccapi -I. -I. -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE -g -O2 -fno-common -Werror=unknown-warning-option -Wall -Wcast-align -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes -Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -Wnewline-eof -Werror=uninitialized -Werror=pointer-arith -Werror=int-conversion -Werror=incompatible-pointer-types -Werror=implicit-int -Werror=declaration-after-statement -Werror-implicit-function-declaration -pthread -c cc_file.c -o cc_file.so.o && mv -f cc_file.so.o cc_file.so [14:57:21] mig -header kcmrpc.h -user kcmrpc.c -sheader /dev/null \ [14:57:21] -server /dev/null -I. ./kcmrpc.defs [14:57:21] make[3]: mig: No such file or directory [14:57:21] make[3]: *** [Makefile:755: kcmrpc.h] Error 127 [14:57:21] make[3]: Leaving directory '/workspace/srcdir/krb5-1.19.3/src/lib/krb5/ccache' [14:57:21] make[2]: *** [Makefile:1155: all-recurse] Error 1 [14:57:21] make[2]: Leaving directory '/workspace/srcdir/krb5-1.19.3/src/lib/krb5' [14:57:21] make[1]: *** [Makefile:1005: all-recurse] Error 1 [14:57:21] make[1]: Leaving directory '/workspace/srcdir/krb5-1.19.3/src/lib' [14:57:21] make: *** [Makefile:1554: all-recurse] Error 1 [14:57:21] ---> make [14:57:21] ---> make [14:57:21] Previous command exited with 2 [14:57:21] Child Process exited, exit code 2 Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Windows
Windows Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos for Windows Logging
Ahh, that explains it, thank you very much Greg! I was hoping to get warning / error level events (i.e. failure to renew a ticket / init). After seeing a few examples of it in win.ini config online I thought there was hope. Thanks again for allowing me to stop this wild goose chase! Patrick Norman Jane Street Group | Information Technology 250 Vesey Street | New York, NY 10281 On Thu, Jan 28, 2021 at 12:48 PM Greg Hudson wrote: > On 1/28/21 11:59 AM, Patrick Norman wrote: > > Hey all, I am looking into using Kerberos for Windows in a POC I am > doing. > > I am having trouble getting logging to work > > The [logging] section is for krb5kdc and kadmind, which are not part of > the Windows build. > > If you want to use trace logging, just set the KRB5_TRACE environment > variable to a filename. > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos for Windows Logging
On 1/28/21 11:59 AM, Patrick Norman wrote: > Hey all, I am looking into using Kerberos for Windows in a POC I am doing. > I am having trouble getting logging to work The [logging] section is for krb5kdc and kadmind, which are not part of the Windows build. If you want to use trace logging, just set the KRB5_TRACE environment variable to a filename. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Kerberos for Windows Logging
Hey all, I am looking into using Kerberos for Windows in a POC I am doing. I am having trouble getting logging to work, all other settings in my INI are working correctly. I have started procmon to check if something is going on with access and it appears nothing is even attempting to access the file path I have defined. There are a few examples I have found through searches, none of them seem to work. I have tried the following (folder exists), nothing seems to work, any help would be appreciated. [logging] default = FILE:C:\Temp\Logs\MITKerberos\krb5libs.log [logging] default = FILE:"C:\Temp\Logs\MITKerberos\krb5libs.log" [logging] default = C:\Temp\Logs\MITKerberos\krb5libs.log [logging] default = "C:\Temp\Logs\MITKerberos\krb5libs.log" [logging] default = 'C:\Temp\Logs\MITKerberos\krb5libs.log' Along with some variants of SYSLOG:INFO, though I cannot find a windows example. If someone could let me know if logging on Windows is supported it would be appreciated. Thank you, Patrick Patrick Norman Jane Street Group | Information Technology 250 Vesey Street | New York, NY 10281 Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Query about kerberos (in windows)
Hi, I'm an administrator of an Active Directory environment. And I need to get the kerberos version of a Microsoft Windows Server operating system by command lines I need to migrate from Windows 2016 to Windows 2019 and I want to see the differences between them. (if there are any) Thank you very much in advance. -- [image: BBVA | Creando Oportunidades] *Ignacio **Martín** Chaffin* *Microinformática** - System Programmer Sr* Tel. +54 11 4340 Interno 11336 – martin.chaf...@bbva.com Torre BBVA – Av. Córdoba 111, Piso 19°, CP 1054 Ciudad Autónoma de Bs. As Antes de imprimir este mensaje, por favor comprueba que es necesario hacerlo. Before you print this message please consider if it is really necessary. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: windows kerberos update?
I just verified that OTP does work. Thanks. > On Jan 16, 2019, at 12:01 PM, Greg Hudson wrote: > > On 1/16/19 11:23 AM, Charles Hedrick wrote: >> We’re starting to use Windows Kerberos, with a 3rd party login screen that >> calls Kerberos. Some of our staff use FreeOTP 2FA. As far as I can tell, the >> most recent KfW doesn’t support 2FA or the https: proxy. > > KfW 4.1 is based on krb5 1.13, which includes the OTP client code, so I > think that's only half correct. > >> Are there plans for a new release that would do so? > > I was planning to do a Windows release based on the 1.17 branch (for > SPAKE support, if nothing else), but I don't have a specific time-table. > > HTTPS proxy support is not currently part of the Windows build, because > of the OpenSSL dependency. I can make an attempt to bring that in when > I make time to do work on the Windows port. (Bringing in an OpenSSL > dependency would also make it possible to enable PKINIT support, though > that might also require some work on the PKINIT code.) > > It is now possible to build the Windows installer from source using the > community (no-cost) version of the MS compiler. See src/windows/README > in the source tree for details. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: windows kerberos update?
Thanks. We’ll try to OTP. If there’s no PKINIT, I guess that means the armor will have to come from the machine credentials. That should be workable. A couple of us do kinit from home on the Mac. I don’t have a long list of people asking for it for Windows, but if a couple of people do it for Mac probably a few would do it for Windows as well. I’m paranoid enough about the server to want use from outside the department to go through the proxy. On Jan 16, 2019, at 12:01:19 PM, Greg Hudson wrote: On 1/16/19 11:23 AM, Charles Hedrick wrote: We’re starting to use Windows Kerberos, with a 3rd party login screen that calls Kerberos. Some of our staff use FreeOTP 2FA. As far as I can tell, the most recent KfW doesn’t support 2FA or the https: proxy. KfW 4.1 is based on krb5 1.13, which includes the OTP client code, so I think that's only half correct. Are there plans for a new release that would do so? I was planning to do a Windows release based on the 1.17 branch (for SPAKE support, if nothing else), but I don't have a specific time-table. HTTPS proxy support is not currently part of the Windows build, because of the OpenSSL dependency. I can make an attempt to bring that in when I make time to do work on the Windows port. (Bringing in an OpenSSL dependency would also make it possible to enable PKINIT support, though that might also require some work on the PKINIT code.) It is now possible to build the Windows installer from source using the community (no-cost) version of the MS compiler. See src/windows/README in the source tree for details. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: windows kerberos update?
On 1/16/19 11:23 AM, Charles Hedrick wrote: > We’re starting to use Windows Kerberos, with a 3rd party login screen that > calls Kerberos. Some of our staff use FreeOTP 2FA. As far as I can tell, the > most recent KfW doesn’t support 2FA or the https: proxy. KfW 4.1 is based on krb5 1.13, which includes the OTP client code, so I think that's only half correct. > Are there plans for a new release that would do so? I was planning to do a Windows release based on the 1.17 branch (for SPAKE support, if nothing else), but I don't have a specific time-table. HTTPS proxy support is not currently part of the Windows build, because of the OpenSSL dependency. I can make an attempt to bring that in when I make time to do work on the Windows port. (Bringing in an OpenSSL dependency would also make it possible to enable PKINIT support, though that might also require some work on the PKINIT code.) It is now possible to build the Windows installer from source using the community (no-cost) version of the MS compiler. See src/windows/README in the source tree for details. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
windows kerberos update?
We’re starting to use Windows Kerberos, with a 3rd party login screen that calls Kerberos. Some of our staff use FreeOTP 2FA. As far as I can tell, the most recent KfW doesn’t support 2FA or the https: proxy. Are there plans for a new release that would do so? Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Authenticate Windows against Kerberos
Hello, I have a well working setup with Kerberos and openldap in multimaster mode. For authentication I use GSSAPI and SASL. Now I have a few Windows machines that should access a few shares on a Samba server. I don't need domain join or AD functionalities. Via Google or in the Samba group always the same answer comes: "Use Samba4 as AD server". I like the current setup, where each part exactly fulfills its task and therefore I don't want to convert to an AD Server, because of a few Windows computers. Is there a simple and reliable way to authenticate Windows computers against Kerberos to access a share? Thanks for every tip or link. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Windows Server 2016 - KDC has no support for encryption type while getting initial credentials
Thank you, Todd Grayson for detailed information.
On Thu, Nov 8, 2018 at 10:07 PM Todd Grayson wrote:
>
> oops, typo by me:
>
> You are hard forcing AES for initial ticket granting ticket with the settings
> you are using for enctypes.
>
> Should read
>
> You are hard forcing AES for initial session key and ticket granting ticket
> with the settings you are using for enctypes.
>
> On Thu, Nov 8, 2018 at 9:35 AM Todd Grayson wrote:
>>
>> You are hard forcing AES for initial ticket granting ticket with the
>> settings you are using for enctypes. Unset (comment out) the 3 enctype
>> lines for one of your tests. How to comment out lines in the krb5.conf is
>> covered in the second paragraph here:
>>
>> https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html
>>
>> Use klist -ef after you successfully authenticate and inspect the ticket
>> encryption types used. It will look something like this after commenting
>> out those lines I mentioned and then retrying your kinit:
>>
>> dude@host:~$ kinit administra...@ad.sec.example.com
>> Password for administra...@ad.sec.example.com:
>> dude@host:~$ klist -ef
>> Ticket cache: FILE:/tmp/krb5cc_1000
>> Default principal: administra...@ad.sec.example.com
>>
>> Valid starting Expires Service principal
>> 11/08/2018 09:16:00 11/08/2018 19:16:00
>> krbtgt/ad.sec.example@ad.sec.example.com
>> renew until 11/15/2018 09:15:53, Flags: FRIA
>> Etype (skey, tkt): arcfour-hmac, aes256-cts-hmac-sha1-96
>>
>> You can see on the Etype line, by default the inital session key is actualy
>> rc4-hmac (arcfour-hmac is same thing, just different names) But the actual
>> ticket granting ticket. The above example is against a windows 2008 KDC, but
>> 2016 is probably doing the same thing for backward comparability.
>>
>>
>> Kerberos will negotiate strongest encryption types by default within the
>> available configuration.
>>
>> AD exposes per user account settings in the properties dialog, under account
>> details, that allow you to set using AES encryption types. Doing it for all
>> accounts would be a global policy in AD. This mail list does not really
>> cover how to manage active directory as a KDC at that level, microsoft
>> discussion boards would be best there.
>>
>> Given you are new to kerberos, I would suggest starting here, reading this
>> will help you understand your terminology, what to search/google for, how
>> things work in kerberos, etc.
>>
>> http://www.kerberos.org/software/tutorial.html
>>
>> The administration guide would be next step.
>>
>> Microsoft AD kerberos info is here, I would start with this AFTER going
>> through the kerberos tutorial.
>>
>> https://docs.microsoft.com/en-us/windows/desktop/secauthn/microsoft-kerberos
>>
>>
>>
>> On Thu, Nov 8, 2018 at 9:03 AM Silambarasan Madhappan
>> wrote:
>>>
>>> Hi,
>>>
>>> I am new to Kerberos. I am not able to obtain Kerberos
>>> ticket-granting tickets with strong encryption types from "Windows
>>> Server 2016 AD"
>>>
>>> My client kerberos configuration as below
>>>
>>>
>>> $ cat /etc/krb5.conf
>>> [libdefaults]
>>> default_realm = CIFS.COM
>>> default_tkt_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
>>> default_tgs_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
>>> preferred_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
>>> ccache_type = 2
>>>
>>> [realms]
>>> CIFS.COM = {
>>> kdc = WIN.cifs.com:88
>>> }
>>>
>>> [domain_realm]
>>> .cifs.com = CIFS.COM
>>>
>>> [logging]
>>> kdc = FILE:/var/log/krb5kdc.log
>>> admin_server = FILE:/var/log/kadmin.log
>>> default = FILE:/var/log/krb5lib.log
>>> [bash4.2]$
>>>
>>> Issue :
>>> =
>>> $ kinit Administrator
>>> kinit(v5): KDC has no support for encryption type while getting
>>> initial credentials
>>> $
>>>
>>> Please let me know where can I find the kdc configuration types in
>>> Active Directory (Windows Server 2016) ?
>>> Do I have to change any configuration on Kerberos Client or Server ?
>>> Please help me on this.
>>>
>>> Thanks,
>>> Silambarasan M
>>>
>>> Kerberos mailing list Kerberos@mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>
>>
>> --
>> Todd Grayson
>> Customer Operations Engineering
>> Security SME
>>
>
>
> --
> Todd Grayson
> Customer Operations Engineering
> Security SME
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Windows Server 2016 - KDC has no support for encryption type while getting initial credentials
oops, typo by me:
You are hard forcing AES for initial ticket granting ticket with the
settings you are using for enctypes.
Should read
You are hard forcing AES for initial session key and ticket granting ticket
with the settings you are using for enctypes.
On Thu, Nov 8, 2018 at 9:35 AM Todd Grayson wrote:
> You are hard forcing AES for initial ticket granting ticket with the
> settings you are using for enctypes. Unset (comment out) the 3 enctype
> lines for one of your tests. How to comment out lines in the krb5.conf is
> covered in the second paragraph here:
>
>
> https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html
>
> Use klist -ef after you successfully authenticate and inspect the ticket
> encryption types used. It will look something like this after commenting
> out those lines I mentioned and then retrying your kinit:
>
> dude@host:~$ kinit administra...@ad.sec.example.com
> Password for administra...@ad.sec.example.com:
> dude@host:~$ klist -ef
> Ticket cache: FILE:/tmp/krb5cc_1000
> Default principal: administra...@ad.sec.example.com
>
> Valid starting Expires Service principal
> 11/08/2018 09:16:00 11/08/2018 19:16:00 krbtgt/
> ad.sec.example@ad.sec.example.com
> renew until 11/15/2018 09:15:53, Flags: FRIA
> Etype (skey, tkt): arcfour-hmac, aes256-cts-hmac-sha1-96
>
> You can see on the Etype line, by default the inital session key is
> actualy rc4-hmac (arcfour-hmac is same thing, just different names) But
> the actual ticket granting ticket. The above example is against a windows
> 2008 KDC, but 2016 is probably doing the same thing for backward
> comparability.
>
>
> Kerberos will negotiate strongest encryption types by default within the
> available configuration.
>
> AD exposes per user account settings in the properties dialog, under
> account details, that allow you to set using AES encryption types. Doing
> it for all accounts would be a global policy in AD. This mail list does
> not really cover how to manage active directory as a KDC at that level,
> microsoft discussion boards would be best there.
>
> Given you are new to kerberos, I would suggest starting here, reading this
> will help you understand your terminology, what to search/google for, how
> things work in kerberos, etc.
>
> http://www.kerberos.org/software/tutorial.html
>
> The administration guide would be next step.
>
> Microsoft AD kerberos info is here, I would start with this AFTER going
> through the kerberos tutorial.
>
>
> https://docs.microsoft.com/en-us/windows/desktop/secauthn/microsoft-kerberos
>
>
>
> On Thu, Nov 8, 2018 at 9:03 AM Silambarasan Madhappan <
> silambarasa...@gmail.com> wrote:
>
>> Hi,
>>
>> I am new to Kerberos. I am not able to obtain Kerberos
>> ticket-granting tickets with strong encryption types from "Windows
>> Server 2016 AD"
>>
>> My client kerberos configuration as below
>>
>>
>> $ cat /etc/krb5.conf
>> [libdefaults]
>> default_realm = CIFS.COM
>> default_tkt_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
>> default_tgs_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
>> preferred_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
>> ccache_type = 2
>>
>> [realms]
>> CIFS.COM = {
>> kdc = WIN.cifs.com:88
>> }
>>
>> [domain_realm]
>> .cifs.com = CIFS.COM
>>
>> [logging]
>> kdc = FILE:/var/log/krb5kdc.log
>> admin_server = FILE:/var/log/kadmin.log
>> default = FILE:/var/log/krb5lib.log
>> [bash4.2]$
>>
>> Issue :
>> =
>> $ kinit Administrator
>> kinit(v5): KDC has no support for encryption type while getting
>> initial credentials
>> $
>>
>> Please let me know where can I find the kdc configuration types in
>> Active Directory (Windows Server 2016) ?
>> Do I have to change any configuration on Kerberos Client or Server ?
>> Please help me on this.
>>
>> Thanks,
>> Silambarasan M
>>
>> Kerberos mailing list Kerberos@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>
>
> --
> Todd Grayson
> Customer Operations Engineering
> Security SME
>
>
--
Todd Grayson
Customer Operations Engineering
Security SME
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Windows Server 2016 - KDC has no support for encryption type while getting initial credentials
You are hard forcing AES for initial ticket granting ticket with the
settings you are using for enctypes. Unset (comment out) the 3 enctype
lines for one of your tests. How to comment out lines in the krb5.conf is
covered in the second paragraph here:
https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html
Use klist -ef after you successfully authenticate and inspect the ticket
encryption types used. It will look something like this after commenting
out those lines I mentioned and then retrying your kinit:
dude@host:~$ kinit administra...@ad.sec.example.com
Password for administra...@ad.sec.example.com:
dude@host:~$ klist -ef
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: administra...@ad.sec.example.com
Valid starting Expires Service principal
11/08/2018 09:16:00 11/08/2018 19:16:00 krbtgt/
ad.sec.example@ad.sec.example.com
renew until 11/15/2018 09:15:53, Flags: FRIA
Etype (skey, tkt): arcfour-hmac, aes256-cts-hmac-sha1-96
You can see on the Etype line, by default the inital session key is actualy
rc4-hmac (arcfour-hmac is same thing, just different names) But the actual
ticket granting ticket. The above example is against a windows 2008 KDC,
but 2016 is probably doing the same thing for backward comparability.
Kerberos will negotiate strongest encryption types by default within the
available configuration.
AD exposes per user account settings in the properties dialog, under
account details, that allow you to set using AES encryption types. Doing
it for all accounts would be a global policy in AD. This mail list does
not really cover how to manage active directory as a KDC at that level,
microsoft discussion boards would be best there.
Given you are new to kerberos, I would suggest starting here, reading this
will help you understand your terminology, what to search/google for, how
things work in kerberos, etc.
http://www.kerberos.org/software/tutorial.html
The administration guide would be next step.
Microsoft AD kerberos info is here, I would start with this AFTER going
through the kerberos tutorial.
https://docs.microsoft.com/en-us/windows/desktop/secauthn/microsoft-kerberos
On Thu, Nov 8, 2018 at 9:03 AM Silambarasan Madhappan <
silambarasa...@gmail.com> wrote:
> Hi,
>
> I am new to Kerberos. I am not able to obtain Kerberos
> ticket-granting tickets with strong encryption types from "Windows
> Server 2016 AD"
>
> My client kerberos configuration as below
>
>
> $ cat /etc/krb5.conf
> [libdefaults]
> default_realm = CIFS.COM
> default_tkt_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
> default_tgs_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
> preferred_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
> ccache_type = 2
>
> [realms]
> CIFS.COM = {
> kdc = WIN.cifs.com:88
> }
>
> [domain_realm]
> .cifs.com = CIFS.COM
>
> [logging]
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmin.log
> default = FILE:/var/log/krb5lib.log
> [bash4.2]$
>
> Issue :
> =
> $ kinit Administrator
> kinit(v5): KDC has no support for encryption type while getting
> initial credentials
> $
>
> Please let me know where can I find the kdc configuration types in
> Active Directory (Windows Server 2016) ?
> Do I have to change any configuration on Kerberos Client or Server ?
> Please help me on this.
>
> Thanks,
> Silambarasan M
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
--
Todd Grayson
Customer Operations Engineering
Security SME
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Windows Server 2016 - KDC has no support for encryption type while getting initial credentials
Hi,
I am new to Kerberos. I am not able to obtain Kerberos
ticket-granting tickets with strong encryption types from "Windows
Server 2016 AD"
My client kerberos configuration as below
$ cat /etc/krb5.conf
[libdefaults]
default_realm = CIFS.COM
default_tkt_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
default_tgs_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
preferred_enctypes = AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
ccache_type = 2
[realms]
CIFS.COM = {
kdc = WIN.cifs.com:88
}
[domain_realm]
.cifs.com = CIFS.COM
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
[bash4.2]$
Issue :
=
$ kinit Administrator
kinit(v5): KDC has no support for encryption type while getting
initial credentials
$
Please let me know where can I find the kdc configuration types in
Active Directory (Windows Server 2016) ?
Do I have to change any configuration on Kerberos Client or Server ?
Please help me on this.
Thanks,
Silambarasan M
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Make Windows Firefox Use Ticket gained via OpenConnect VPN Connection
The description of current and desired behavior is a bit sparse, but it seems like the key question is whether/where openconnect stores the kerberos ticket obtained during VPN connection. If it's stored someplace accessible, the rest would just be a matter of getting the different tools plumbed together properly. But if the KfW ticket manager does not show any credentials after the openconnect login, it may be that openconnect is not storing the ticket anywhere, in which case a software change would be needed to openconnect to get it to do so. -Ben On Sat, Oct 20, 2018 at 10:09:57PM +0200, chiasa.men wrote: > I have an openconnect server where I can login with kerberos credentials (the > vpn server basically also works as proxy to the kdc within said vpn - more > detailed description: https://access.redhat.com/blogs/766093/posts/1976663) > > Now I can connect with a windows machine (using openconnect-gui) with my > kerberos credentials. Which works. > > The next step shall be to use the gained ticket further for webservices > within > that vpn. How can I tell the browser (e.g. Firefox) to use the ticket gained > by openconnect? Is there any way to achieve this? > > I also installed the MIT Kerberos Ticket Manager for Windows. Here (https:// > community.hortonworks.com/content/kbentry/28537/user-authentication-from- > windows-workstation-to-hd.html) is desribed that it is possible to use that > Manager with firefox in order to authenticate to webservices. Although I > haven't been able to accomplish that, would it be possible to tell MIT > Kerberos Ticket Manager to use the Ticket of the vpn login? > > Is there already a 'usual way' to achieve something like sso via vpn with > kerberos with windows clients? > > > > > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Make Windows Firefox Use Ticket gained via OpenConnect VPN Connection
I have an openconnect server where I can login with kerberos credentials (the vpn server basically also works as proxy to the kdc within said vpn - more detailed description: https://access.redhat.com/blogs/766093/posts/1976663) Now I can connect with a windows machine (using openconnect-gui) with my kerberos credentials. Which works. The next step shall be to use the gained ticket further for webservices within that vpn. How can I tell the browser (e.g. Firefox) to use the ticket gained by openconnect? Is there any way to achieve this? I also installed the MIT Kerberos Ticket Manager for Windows. Here (https:// community.hortonworks.com/content/kbentry/28537/user-authentication-from- windows-workstation-to-hd.html) is desribed that it is possible to use that Manager with firefox in order to authenticate to webservices. Although I haven't been able to accomplish that, would it be possible to tell MIT Kerberos Ticket Manager to use the Ticket of the vpn login? Is there already a 'usual way' to achieve something like sso via vpn with kerberos with windows clients? Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Phoenix ODBC client on Windows connecting to Kerberos Hadoop Phoenix is throwing error “GSSException: Defective token detected”
A couple things: (1) You are using kfw to kinit but using the Windows "klist" to look at tickets. Windows has a native klist command of its own that pulls from its memory-based credentials cache. Make sure to use the MIT "klist" from the command line tool or the KFW UI (2) The ODBC client uses SPNEGO and the exception is saying "GSSHeader did not find the right tag". The error is pretty generic, but usually indicates that there was something wrong getting a Service Ticket on the client side. - Use MIT KFW klist or KFW UI to make sure you obtain the HTTP principal service ticket for your connection to the server. - set KRB5_TRACE environment variable in order to get tracing to determine if there are any problems obtaining the service ticket - Verify your krb5.ini configuration and that KRB5_CONFIG and KRB5CCNAME are set appropriately for your configuration. Bottom line is that the situation you see can be caused by a lot of different things, so making sure you can obtain a service ticket and tat it appears in your credentials cache is the first step. On Wed, Sep 5, 2018 at 4:22 AM ANILESH_TENNETI wrote: > HiCan you please respond to my email?Thanks,AnilFrom: & > quot;ANILESH_TENNETI"<venkata_a...@rediffmail.com>Sent: Wed, > 08 Aug 2018 14:49:27To: <kerberos@mit.edu>Subject: Phoenix ODBC > client on Windows connecting to Kerberos Hadoop Phoenix is throwing error > “GSSException: Defective token detected”Hi,Hello MIT > team, I'm Anil working for IBM and implemented Kebreros for a > customer. Kerberos – AD is implemented on Hadoop environment. > Phoenix is enabled to open JDBC / ODBC connection to Hadoop HBase. Hadoop > is setup on RHEL 7.2Windows client machines connecting to Hadoop Phoenix > using Hortonworks Phoenix ODBC driver (64 bit). As connection should be > established to Kerberos Phoenix, the Windows ODBC client machine also must > be setup with Kerberos.Windows odbc client machine has been setup with MIT > Kerberos as per the documentation link > https://community.hortonworks.com/articles/28537/user-authentication-from-windows-workstation-to-hd.h > ! > tmlCopied the krb5.conf file to windows machine as krb5.ini. Using > MIT Kerberos key tool, get new Kerberos ticket say for user > ‘kpiuser’ as shown below;On establishing connection from ODBC > client, phoenix connection fails with log message “GSSException: > Defective token detected (Mechanism level: GSSHeader did not find the right > tag)”.Refer to Error-in-phoenix-log.txtThis implies, the Kerberos > ticket format is different or corrupted.The phoenix ODBC client logs shows > connection errors.Refer to HortonworksPhoenixODBCDriver_connection_1.log > and phoenix_driver.logOn windows client machine, doing kinit for a user > does not show the cached ticket when run klist command.Refer to > klist-on-windows-odbc-client.txtThanks,Anil > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > -- Ben Gooley *Customer Operations Engineer* * <http://www.cloudera.com>* Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Phoenix ODBC client on Windows connecting to Kerberos Hadoop Phoenix is throwing error “GSSException: Defective token detected”
HiCan you please respond to my email?Thanks,AnilFrom: "ANILESH_TENNETI"<venkata_a...@rediffmail.com>Sent: Wed, 08 Aug 2018 14:49:27To: <kerberos@mit.edu>Subject: Phoenix ODBC client on Windows connecting to Kerberos Hadoop Phoenix is throwing error “GSSException: Defective token detected”Hi,Hello MIT team, I'm Anil working for IBM and implemented Kebreros for a customer. Kerberos – AD is implemented on Hadoop environment. Phoenix is enabled to open JDBC / ODBC connection to Hadoop HBase. Hadoop is setup on RHEL 7.2Windows client machines connecting to Hadoop Phoenix using Hortonworks Phoenix ODBC driver (64 bit). As connection should be established to Kerberos Phoenix, the Windows ODBC client machine also must be setup with Kerberos.Windows odbc client machine has been setup with MIT Kerberos as per the documentation link https://community.hortonworks.com/articles/28537/user-authentication-from-windows-workstation-to-hd.h! tmlCopied the krb5.conf file to windows machine as krb5.ini. Using MIT Kerberos key tool, get new Kerberos ticket say for user ‘kpiuser’ as shown below;On establishing connection from ODBC client, phoenix connection fails with log message “GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)”.Refer to Error-in-phoenix-log.txtThis implies, the Kerberos ticket format is different or corrupted.The phoenix ODBC client logs shows connection errors.Refer to HortonworksPhoenixODBCDriver_connection_1.log and phoenix_driver.logOn windows client machine, doing kinit for a user does not show the cached ticket when run klist command.Refer to klist-on-windows-odbc-client.txtThanks,Anil Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Phoenix ODBC client on Windows connecting to Kerberos Hadoop Phoenix is throwing error “GSSException: Defective token detected”
Hi,Hello MIT team, I'm Anil working for IBM and implemented Kebreros for a customer. Kerberos – AD is implemented on Hadoop environment. Phoenix is enabled to open JDBC / ODBC connection to Hadoop HBase. Hadoop is setup on RHEL 7.2Windows client machines connecting to Hadoop Phoenix using Hortonworks Phoenix ODBC driver (64 bit). As connection should be established to Kerberos Phoenix, the Windows ODBC client machine also must be setup with Kerberos.Windows odbc client machine has been setup with MIT Kerberos as per the documentation link https://community.hortonworks.com/articles/28537/user-authentication-from-windows-workstation-to-hd.htmlCopied the krb5.conf file to windows machine as krb5.ini. Using MIT Kerberos key tool, get new Kerberos ticket say for user ‘kpiuser’ as shown below;On establishing connection from ODBC client, phoenix connection fails with log message “GSSException: Defective token detected (Mechanism level: GSS! Header did not find the right tag)”.Refer to Error-in-phoenix-log.txtThis implies, the Kerberos ticket format is different or corrupted.The phoenix ODBC client logs shows connection errors.Refer to HortonworksPhoenixODBCDriver_connection_1.log and phoenix_driver.logOn windows client machine, doing kinit for a user does not show the cached ticket when run klist command.Refer to klist-on-windows-odbc-client.txtThanks,Anil 2018-07-10 19:28:16,272 WARN org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) at sun.security.jgss.GSSHeader.(GSSHeader.java:97) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:306) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285) at org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService.login(SpnegoLoginService.java:137) at org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.LoginAuthenticator.login(LoginAuthenticator.java:61) at org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.SpnegoAuthenticator.validateRequest(SpnegoAuthenticator.java:99) at org.apache.phoenix.shaded.org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:512) at org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52) at org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.apache.phoenix.shaded.org.eclipse.jetty.server.Server.handle(Server.java:499) at org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311) at org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.apache.phoenix.shaded.org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544) at org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) 2018-07-10 19:28:16,276 WARN org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) at sun.security.jgss.GSSHeader.(GSSHeader.java:97) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:306) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285) at org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService.login(SpnegoLoginService.java:137) at org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.LoginAuthenticator.login(LoginAuthenticator.java:61) at org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.SpnegoAuthenticator.validateRequest(SpnegoAuthenticator.java:99) at org.apache.phoenix.shaded.org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:512) at org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52) at org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.apache.phoenix.shaded.org.eclipse.jetty.server.Server.handle(Server.java:499) at org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311) at org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.apache.phoenix.shaded.org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544) at org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
Thanks very much, that clarifies my problems.
I must have clicked on "Make default", and it has the API settings in
the registry.
I can't find any button to undo that - If I've changed something in
krb.ini, click "Make default", then afterwards I'm stuck with those
settings until I manually edit the registry?
Odd.
But If I use the API settings, all is well and logging in with GSSAPI or
Kerberized telnet works the way it should.
I'll update my docs to reflect that in case my users run into this problem.
Thanks again for the help,
Ruurd
Op 19-6-2018 om 22:25 schreef Greg Hudson:
> On 06/19/2018 03:51 PM, Ruurd Beerstra wrote:
>> OK, I'm confused now
>> 2 days ago I tried FILE: by editing krb5.ini and setting
>> default_cc_name to FILE:c:/tmp/krb5cc_${uid}
>> I saw it uses the SID for my user as part of the filename in c:/tmp.
>> I SAW the file being made, and it STILL refused to work the way it
>> should. The ticket manager showed "FILE:.." in the "Credential cache"
>> column.
> I'm not sure if I can completely explain this, but it's [libdefaults]
> default_ccache_name, not default_cc_name.
>
>> Start the "MIT kerberos.exe", get a TGT: The Credential cache" still
>> shows "API: Initial default ccache". Huh? Why does it not go back to
>> MSLSA?
>
> Three's a registry value HKCU\Software\MIT\Kerberos5 ccname, which the
> ticket manager sets if you click "make default".
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
OK, I'm confused now
2 days ago I tried FILE: by editing krb5.ini and setting default_cc_name
to FILE:c:/tmp/krb5cc_${uid}
I saw it uses the SID for my user as part of the filename in c:/tmp.
I SAW the file being made, and it STILL refused to work the way it
should. The ticket manager showed "FILE:.." in the "Credential cache"
column.
I tried your API suggestion last night, saw "API: Initial default cache:
in the ticket manager and it still did not work.
Then I tried again tonight, by using "kvno" to acquire a ticket. And all
of sudden, the host service ticket appears in the ticket manager!
Fire up IVT: It uses the ticket and logs in with Kerberized telnet and
GSSAPI-over-SSH like it should.
Destroy the TGT and other tickets, restart IVT: It pops up the ticket
manager, I type the proper password, tickets are acquired: Everything works.
No clue as to why it started working all of a sudden, but I'm happy!
So I wanted to go through the proper steps again so I could document it
in IVT in case a user runs into this issue.
I change the krb5.ini file back to the default empty:
Directory of C:\ProgramData\MIT\Kerberos5
19-06-2018 21:03 .
19-06-2018 21:03 ..
19-06-2018 21:04 0 krb5.ini
1 File(s) 0 bytes
Start the "MIT kerberos.exe", get a TGT: The Credential cache" still
shows "API: Initial default ccache". Huh? Why does it not go back to MSLSA?
Reboot. No difference. API.
Search Registry for things called MIT and/od ccache: Found nothing relevant.
Search file system for things called krb5.ini: Nothing relevant.
So now it keeps working despite everything I try to break it.
Admittedly, progress is made, but I want to understand what happens here!
Can someone here point me in the right direction?
Where am I supposed to configure MSLSA if I want to force the problem again?
Where does it store the current API setting?
What did I do wrong the time I tried the FILE: setting?
Help very much appreciated,
Ruurd
Op 18-6-2018 om 23:31 schreef Greg Hudson:
> On 06/18/2018 12:25 PM, Ruurd Beerstra wrote:
>> I probably should have mentioned I tried setting the ccache type to
>> "FILE", and that didn't work either.
>
> Just "FILE"? You need to set it to "FILE:pathname" for some pathname.
>
> I don't have a hypothesis to explain why "API:" wouldn't work. I
> updated a Windows 10 VM to 1803 and installed the kfw 4.1 MSI. With
> the API: ccache type I was able to acquire tickets, renew tickets,
> acquire service tickets using kvno, and see the acquired service
> ticket with klist.
>
> With the MSLSA: ccache type it does seem like I can't access the TGT
> session key. I can acquire a TGT and can view it in the graphical
> ticket manager (but not with klist; not sure why). Renewing the TGT
> doesn't appear to work, although I only see an error message if I run
> "kinit -R" from the command line (same error as you saw, "Matching
> credential not found"); with the graphical ticket manager it seems to
> silently fail. I can obtain a service ticket and view that with
> klist, but from tracing output it is clear that that is happening
> through the LSA (which is probably able to find the realm I'm testing
> against using SRV records in DNS).
>
>> A quick search on Credential Guard says: The Windows Defender Credential
>> Guard prevents these attacks by protecting NTLM password hashes,
>> Kerberos Ticket Granting Tickets, and credentials stored by applications
>> as domain credentials.
>
> To be clear, my uncomfirmed hypothesis is that update 1803 made the
> HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos AllowTGTSessionKey
> registry variable inoperable, with or without Credential Guard. An
> additional restriction on access to service ticket session keys does
> not seem to match the errors you're seeing.
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
On 06/19/2018 03:51 PM, Ruurd Beerstra wrote:
> OK, I'm confused now
> 2 days ago I tried FILE: by editing krb5.ini and setting default_cc_name
> to FILE:c:/tmp/krb5cc_${uid}
> I saw it uses the SID for my user as part of the filename in c:/tmp.
> I SAW the file being made, and it STILL refused to work the way it
> should. The ticket manager showed "FILE:.." in the "Credential cache"
> column.
I'm not sure if I can completely explain this, but it's [libdefaults]
default_ccache_name, not default_cc_name.
> Start the "MIT kerberos.exe", get a TGT: The Credential cache" still
> shows "API: Initial default ccache". Huh? Why does it not go back to MSLSA?
Three's a registry value HKCU\Software\MIT\Kerberos5 ccname, which the
ticket manager sets if you click "make default".
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
On Mon, Jun 18, 2018 at 05:31:33PM -0400, Greg Hudson wrote: > On 06/18/2018 12:25 PM, Ruurd Beerstra wrote: > > I probably should have mentioned I tried setting the ccache type to > > "FILE", and that didn't work either. > > Just "FILE"? You need to set it to "FILE:pathname" for some pathname. > > I don't have a hypothesis to explain why "API:" wouldn't work. I > updated a Windows 10 VM to 1803 and installed the kfw 4.1 MSI. With the > API: ccache type I was able to acquire tickets, renew tickets, acquire > service tickets using kvno, and see the acquired service ticket with klist. > > With the MSLSA: ccache type it does seem like I can't access the TGT > session key. I can acquire a TGT and can view it in the graphical > ticket manager (but not with klist; not sure why). Renewing the TGT I think the magic there is at https://github.com/krb5/krb5/blob/master/src/windows/leash/KrbListTickets.cpp#L201 > doesn't appear to work, although I only see an error message if I run > "kinit -R" from the command line (same error as you saw, "Matching > credential not found"); with the graphical ticket manager it seems to > silently fail. I can obtain a service ticket and view that with klist, > but from tracing output it is clear that that is happening through the > LSA (which is probably able to find the realm I'm testing against using > SRV records in DNS). My recollection was that you needed something in the registry (at the path I mentioned in my previous mail) even to get the LSA to look for SRV records. (Do I know what realm you're testing with?) IIRC the KfW installer does prepopulate KDC entries for a couple of realms, as an example if nothing else.) -Ben > > A quick search on Credential Guard says: The Windows Defender Credential > > Guard prevents these attacks by protecting NTLM password hashes, > > Kerberos Ticket Granting Tickets, and credentials stored by applications > > as domain credentials. > > To be clear, my uncomfirmed hypothesis is that update 1803 made the > HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos AllowTGTSessionKey > registry variable inoperable, with or without Credential Guard. An > additional restriction on access to service ticket session keys does not > seem to match the errors you're seeing. > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
On 06/18/2018 12:25 PM, Ruurd Beerstra wrote: > I probably should have mentioned I tried setting the ccache type to > "FILE", and that didn't work either. Just "FILE"? You need to set it to "FILE:pathname" for some pathname. I don't have a hypothesis to explain why "API:" wouldn't work. I updated a Windows 10 VM to 1803 and installed the kfw 4.1 MSI. With the API: ccache type I was able to acquire tickets, renew tickets, acquire service tickets using kvno, and see the acquired service ticket with klist. With the MSLSA: ccache type it does seem like I can't access the TGT session key. I can acquire a TGT and can view it in the graphical ticket manager (but not with klist; not sure why). Renewing the TGT doesn't appear to work, although I only see an error message if I run "kinit -R" from the command line (same error as you saw, "Matching credential not found"); with the graphical ticket manager it seems to silently fail. I can obtain a service ticket and view that with klist, but from tracing output it is clear that that is happening through the LSA (which is probably able to find the realm I'm testing against using SRV records in DNS). > A quick search on Credential Guard says: The Windows Defender Credential > Guard prevents these attacks by protecting NTLM password hashes, > Kerberos Ticket Granting Tickets, and credentials stored by applications > as domain credentials. To be clear, my uncomfirmed hypothesis is that update 1803 made the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos AllowTGTSessionKey registry variable inoperable, with or without Credential Guard. An additional restriction on access to service ticket session keys does not seem to match the errors you're seeing. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
Hi, Thanks for the quick reply. The first screenshot showed a popup from MIT Kerberos (Title "Kerberos Five") saying: Matching credential not found. Kerberos error -1765328243. krb5_get_renewed_creds() failed. The 2nd was the ticket manager showing just my TGT and nothing else. I probably should have mentioned I tried setting the ccache type to "FILE", and that didn't work either. I tried "API" just now (didn't know that one), the ticket manager shows "API: Initial default ccache" in its "Credential cache" column. But no joy: IVT and Putty both fail to use GSSAPI, and IVT also fails on Kerberized telnet. Tried reboot of my workstation: No change. Both IVT and Putty cause the ticket-manager to pop up to obtain new credentials, because they do not see my TGT (and so allow me to obtain one). The AllowTGTSessionKey is set in the registry, value 1. A quick search on Credential Guard says: The Windows Defender Credential Guard prevents these attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets, and credentials stored by applications as domain credentials. And that sounds like exactly my problem. I can't find any way to turn that protection off. I don't understand why a FILE: or API: based ccache would be affected by this Credential Guard, but I can't get any GSSAPI or Kerberized telnet session to work anymore. And up until recently (I have automated regression tests fror IVT) that was not a problem. Bedtime here now, maybe more tomorrow, Thanks again, Ruurd Op 17-6-2018 om 22:35 schreef Greg Hudson: > On 06/17/2018 02:02 PM, Ruurd Beerstra wrote: >> The symptoms are that I can obtain a TGT from my KDC (which ends up in >> de LSA of Windows), but every attempt to use that TGT to obtain a >> service ticket yields an error: >> Matching credential not found. > > Unfortunately, our mailing list server doesn't pass through > attachments, so while I briefly saw your screenshots before moderating > through your message, they didn't make it to the list (and I didn't > keep a copy.) > > I believe the correct short answer is to use the "API:" ccache instead > of the "MSLSA:" ccache for this setup. > > For some time Windows has restricted access to TGT session keys in the > LSA, which means our libkrb5 code can't use a TGT from the LSA to get > service tickets. Instead, our MSLSA ccache type requests service > tickets via Windows, but that only works if the realm is set up in the > LSA configuration. Since you are using an MIT krb5 KDC, I am guessing > that it is not set up in the LSA configuration, so we fall back to > trying to get service tickets using the TGT. > > The TGT session key restriction can be overridden by the registry > value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos > AllowTGTSessionKey, which I believe our installer sets. I would not > be surprised if update 1803 disables this registry value so that the > restriction is always in effect. > > I have also heard that Microsoft plans to disable access to service > ticket session keys from userspace, effectively preventing KfW from > using the LSA ccache. I don't know if that restriction is present in > update 1803, and I believe it only applies if Credential Guard is > enabled. (I don't know what determines whether Credential Guard is > enabled.) We could conceivably work around this restriction in the > GSSAPI library by getting context establishment tokens via SSPI > instead of via our krb5 code, but I can't make any promises as to when > that might be implemented. I don't believe this is the restriction at > issue in your test setup anyway. > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
On Sun, Jun 17, 2018 at 04:35:50PM -0400, Greg Hudson wrote: > On 06/17/2018 02:02 PM, Ruurd Beerstra wrote: > > The symptoms are that I can obtain a TGT from my KDC (which ends up in > > de LSA of Windows), but every attempt to use that TGT to obtain a > > service ticket yields an error: > > Matching credential not found. > > Unfortunately, our mailing list server doesn't pass through attachments, > so while I briefly saw your screenshots before moderating through your > message, they didn't make it to the list (and I didn't keep a copy.) > > I believe the correct short answer is to use the "API:" ccache instead > of the "MSLSA:" ccache for this setup. > > For some time Windows has restricted access to TGT session keys in the > LSA, which means our libkrb5 code can't use a TGT from the LSA to get > service tickets. Instead, our MSLSA ccache type requests service > tickets via Windows, but that only works if the realm is set up in the > LSA configuration. Since you are using an MIT krb5 KDC, I am guessing > that it is not set up in the LSA configuration, so we fall back to > trying to get service tickets using the TGT. Does this mean that you think setting the appropriate entries under SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains would resolve the issue? -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
On 06/17/2018 02:02 PM, Ruurd Beerstra wrote: > The symptoms are that I can obtain a TGT from my KDC (which ends up in > de LSA of Windows), but every attempt to use that TGT to obtain a > service ticket yields an error: > Matching credential not found. Unfortunately, our mailing list server doesn't pass through attachments, so while I briefly saw your screenshots before moderating through your message, they didn't make it to the list (and I didn't keep a copy.) I believe the correct short answer is to use the "API:" ccache instead of the "MSLSA:" ccache for this setup. For some time Windows has restricted access to TGT session keys in the LSA, which means our libkrb5 code can't use a TGT from the LSA to get service tickets. Instead, our MSLSA ccache type requests service tickets via Windows, but that only works if the realm is set up in the LSA configuration. Since you are using an MIT krb5 KDC, I am guessing that it is not set up in the LSA configuration, so we fall back to trying to get service tickets using the TGT. The TGT session key restriction can be overridden by the registry value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos AllowTGTSessionKey, which I believe our installer sets. I would not be surprised if update 1803 disables this registry value so that the restriction is always in effect. I have also heard that Microsoft plans to disable access to service ticket session keys from userspace, effectively preventing KfW from using the LSA ccache. I don't know if that restriction is present in update 1803, and I believe it only applies if Credential Guard is enabled. (I don't know what determines whether Credential Guard is enabled.) We could conceivably work around this restriction in the GSSAPI library by getting context establishment tokens via SSPI instead of via our krb5 code, but I can't make any promises as to when that might be implemented. I don't believe this is the restriction at issue in your test setup anyway. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
MIT Kerberos for Windows failing with Windows 10 update 1803?
Hi, I'm developer of a Windows SSH/Telnet client (called IVT) that supports both GSSAPI authentication and Kerberized telnet. I've noticed that the setup I use for regression testing now finds errors for both protocols: Login fails. After a lot of digging, I'm suspecting Windows 10 privacy update (1803) that was pushed to my development workstation a short while ago. The symptoms are that I can obtain a TGT from my KDC (which ends up in de LSA of Windows), but every attempt to use that TGT to obtain a service ticket yields an error: Matching credential not found. When I install a copy of the software on a Windows 7 Virtual Box machine (same network, same KDC, same user/principal, same IVT version, same Kerberos for Windows version 4.1, etc) it works flawlessly. I was about to go single stepping through my code to find the problem, but when I woke the PC to start work on that, I noticed that the MIT software itself has the same problem! This popup appeared: So that is Kerberos for Windows trying to refresh my credentials and running into the very same error. Apparently it cannot access the TGT either. I found this article https://www.csoonline.com/article/3253899/windows/the-best-new-windows-10-security-features.html about all sorts of new security features in Windows 10 and that sounds like Microsoft may have changed something that breaks Kerberos? When I use a sniffer on my network I can see that there is no communication between my Telnet client and the KDC when it is supposed to request a ticket for the host I'm logging in to. So there is no error logged on the KDC either (I jusyt see an entry when I login to get my TGT). Some details about the environment: - KDC is MIT version krb5-1.16.1 - kfw-4.1-amd64.msi, freshly (re)installed - Target is a Linux box with a ktelnetd on it, but all that does is saying "DO AUTH" and then when I try to get a ticket it fails. - PC is Windows 10 Home edition, version 1803 build 17134.112 Everything worked until about two weeks ago (1803 was installed on 5th of June). I can get my TGT: but that is all I ever see, no tickets for the host I'm trying to login to. Insights very much appreciated, please reply to ruu...@wxs.nl. Regards, Ruurd Beerstra Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
On 11/02/2017 07:33 PM, Benjamin Kaduk wrote: > Hmm, could you say a bit more about what version of KfW you're using and > how you've tried to configure MS-KKDCP? From the release notes, at least, > it seems that KfW 4.1 should have this support available in some form. The TLS part of MS-KKDCP (which is mandatory; there's no non-HTTPS proxy mode) is implemented as an auto-loaded plugin module linked against OpenSSL. Although I believe we have working module loading support for Windows, the Windows build doesn't compile any plugin modules and doesn't link against OpenSSL. So this feature unfortunately didn't make it into KfW, for mostly the same reasons as PKINIT isn't supported. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
It works fine in a copy of Ubuntu running in Linux for Windows on the same Windows 10 machine. > On Nov 3, 2017, at 9:53 AM, Charles Hedrick wrote: > > Here’s the conversation using tcpdump on the proxy server. The connection > opens, no data is sent in either direction, and KfW closes it. > > In case it matters, KfW is running in Windows 10 Fall Creator’s Update in a > VM on a Mac. > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes > 09:48:51.655867 IP heidelberg.cs.rutgers.edu.64543 > > services.cs.rutgers.edu.https: Flags [S], seq 1112026556, win 65535, options > [mss 1460,nop,wscale 5,nop,nop,TS val 348866560 ecr 0,sackOK,eol], length 0 > 09:48:51.655986 IP services.cs.rutgers.edu.https > > heidelberg.cs.rutgers.edu.64543: Flags [S.], seq 990987710, ack 1112026557, > win 28960, options [mss 1460,sackOK,TS val 32546177 ecr 348866560,nop,wscale > 7], length 0 > 09:48:51.656291 IP heidelberg.cs.rutgers.edu.64543 > > services.cs.rutgers.edu.https: Flags [.], ack 1, win 4117, options > [nop,nop,TS val 348866560 ecr 32546177], length 0 > 09:48:51.656783 IP heidelberg.cs.rutgers.edu.64543 > > services.cs.rutgers.edu.https: Flags [F.], seq 1, ack 1, win 4117, options > [nop,nop,TS val 348866560 ecr 32546177], length 0 > 09:48:51.657145 IP services.cs.rutgers.edu.https > > heidelberg.cs.rutgers.edu.64543: Flags [F.], seq 1, ack 2, win 227, options > [nop,nop,TS val 32546178 ecr 348866560], length 0 > 09:48:51.657401 IP heidelberg.cs.rutgers.edu.64543 > > services.cs.rutgers.edu.https: Flags [.], ack 2, win 4117, options > [nop,nop,TS val 348866561 ecr 32546178], length 0 > > >> On Nov 3, 2017, at 9:30 AM, Charles Hedrick wrote: >> >> I’m using KfW 4.1. Since there’s no documentation on krb5.ini, I used the >> same syntax as for krb5.conf >> >> kdc = >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservices.cs.rutgers.edu%2FKdcProxy&data=02%7C01%7Chedrick%40rutgers.edu%7Cc5a5c58bfd4c4b5356c508d522bf5ffa%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636453127701447995&sdata=BfTwuAAxnIuu1H0RpVWLHcdUIC%2FE7th8V5Gjf0EMg8g%3D&reserved=0 >> >> I’m not using http_anchor, since we have a commercial cert, and other >> implementations don’t need us to specify a CA cert. >> >> The error message says no kdc is reachable. >> >> On Nov 2, 2017, at 7:33 PM, Benjamin Kaduk >> mailto:ka...@mit.edu>> wrote: >> >> On Wed, Nov 01, 2017 at 10:30:36PM +, Charles Hedrick wrote: >> >> I’ll try agian. Also KfW doesn’t seem to implement kdc proxy. I’d prefer not >> to open my kdc to the world. I’m currrently using the Proxy for home use. >> >> Hmm, could you say a bit more about what version of KfW you're using and >> how you've tried to configure MS-KKDCP? From the release notes, at least, >> it seems that KfW 4.1 should have this support available in some form. >> >> -Ben >> >> >> Kerberos mailing list Kerberos@mit.edu >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=02%7C01%7Chedrick%40rutgers.edu%7Cc5a5c58bfd4c4b5356c508d522bf5ffa%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636453127701447995&sdata=KYGuhWAWrMMoTNtVLcDUzAEXQ46wZFJqi7z1c4S%2FIgc%3D&reserved=0 > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
Here’s the conversation using tcpdump on the proxy server. The connection opens, no data is sent in either direction, and KfW closes it. In case it matters, KfW is running in Windows 10 Fall Creator’s Update in a VM on a Mac. tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes 09:48:51.655867 IP heidelberg.cs.rutgers.edu.64543 > services.cs.rutgers.edu.https: Flags [S], seq 1112026556, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 348866560 ecr 0,sackOK,eol], length 0 09:48:51.655986 IP services.cs.rutgers.edu.https > heidelberg.cs.rutgers.edu.64543: Flags [S.], seq 990987710, ack 1112026557, win 28960, options [mss 1460,sackOK,TS val 32546177 ecr 348866560,nop,wscale 7], length 0 09:48:51.656291 IP heidelberg.cs.rutgers.edu.64543 > services.cs.rutgers.edu.https: Flags [.], ack 1, win 4117, options [nop,nop,TS val 348866560 ecr 32546177], length 0 09:48:51.656783 IP heidelberg.cs.rutgers.edu.64543 > services.cs.rutgers.edu.https: Flags [F.], seq 1, ack 1, win 4117, options [nop,nop,TS val 348866560 ecr 32546177], length 0 09:48:51.657145 IP services.cs.rutgers.edu.https > heidelberg.cs.rutgers.edu.64543: Flags [F.], seq 1, ack 2, win 227, options [nop,nop,TS val 32546178 ecr 348866560], length 0 09:48:51.657401 IP heidelberg.cs.rutgers.edu.64543 > services.cs.rutgers.edu.https: Flags [.], ack 2, win 4117, options [nop,nop,TS val 348866561 ecr 32546178], length 0 > On Nov 3, 2017, at 9:30 AM, Charles Hedrick wrote: > > I’m using KfW 4.1. Since there’s no documentation on krb5.ini, I used the > same syntax as for krb5.conf > > kdc = > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservices.cs.rutgers.edu%2FKdcProxy&data=02%7C01%7Chedrick%40rutgers.edu%7Cc5a5c58bfd4c4b5356c508d522bf5ffa%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636453127701447995&sdata=BfTwuAAxnIuu1H0RpVWLHcdUIC%2FE7th8V5Gjf0EMg8g%3D&reserved=0 > > I’m not using http_anchor, since we have a commercial cert, and other > implementations don’t need us to specify a CA cert. > > The error message says no kdc is reachable. > > On Nov 2, 2017, at 7:33 PM, Benjamin Kaduk > mailto:ka...@mit.edu>> wrote: > > On Wed, Nov 01, 2017 at 10:30:36PM +, Charles Hedrick wrote: > > I’ll try agian. Also KfW doesn’t seem to implement kdc proxy. I’d prefer not > to open my kdc to the world. I’m currrently using the Proxy for home use. > > Hmm, could you say a bit more about what version of KfW you're using and > how you've tried to configure MS-KKDCP? From the release notes, at least, > it seems that KfW 4.1 should have this support available in some form. > > -Ben > > > Kerberos mailing list Kerberos@mit.edu > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=02%7C01%7Chedrick%40rutgers.edu%7Cc5a5c58bfd4c4b5356c508d522bf5ffa%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636453127701447995&sdata=KYGuhWAWrMMoTNtVLcDUzAEXQ46wZFJqi7z1c4S%2FIgc%3D&reserved=0 Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
I’m using KfW 4.1. Since there’s no documentation on krb5.ini, I used the same syntax as for krb5.conf kdc = https://services.cs.rutgers.edu/KdcProxy I’m not using http_anchor, since we have a commercial cert, and other implementations don’t need us to specify a CA cert. The error message says no kdc is reachable. On Nov 2, 2017, at 7:33 PM, Benjamin Kaduk mailto:ka...@mit.edu>> wrote: On Wed, Nov 01, 2017 at 10:30:36PM +, Charles Hedrick wrote: I’ll try agian. Also KfW doesn’t seem to implement kdc proxy. I’d prefer not to open my kdc to the world. I’m currrently using the Proxy for home use. Hmm, could you say a bit more about what version of KfW you're using and how you've tried to configure MS-KKDCP? From the release notes, at least, it seems that KfW 4.1 should have this support available in some form. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
On Wed, Nov 01, 2017 at 10:30:36PM +, Charles Hedrick wrote: > > I’ll try agian. Also KfW doesn’t seem to implement kdc proxy. I’d prefer not > to open my kdc to the world. I’m currrently using the Proxy for home use. Hmm, could you say a bit more about what version of KfW you're using and how you've tried to configure MS-KKDCP? From the release notes, at least, it seems that KfW 4.1 should have this support available in some form. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
I’ll try agian. Also KfW doesn’t seem to implement kdc proxy. I’d prefer not to open my kdc to the world. I’m currrently using the Proxy for home use. > On Nov 1, 2017, at 2:30:55 PM, Benjamin Kaduk wrote: > > On Wed, Nov 01, 2017 at 06:06:23PM +, Charles Hedrick wrote: >> >> My problem with KfW is more serious: I can’t get putty to see the tickets. >> That makes it of no real use to me. I’m going to try installing Ubuntu on >> Windows. > > I was able to reliably get putty working with GSSAPI/Kerberos when I was > working on KfW. The putty settings were kind of buried, though. > I guess > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pdc.kth.se%2Fresources%2Fsoftware%2Flogin-1%2Fwindows%2Fputty&data=02%7C01%7Chedrick%40rutgers.edu%7C521eeb656f7b42ebd83f08d52156b789%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636451578683920759&sdata=zDfnligBmlY1W9mDPKxXYKffvGEbRwJfUgX0t2pnT7s%3D&reserved=0 > suggests > that Connection-->SSH-->Auth-->GSSAPI is where the checkboxes are hiding, > though there may have been one other thing that needed tweaking. > > Hope this helps, > > Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
On Wed, Nov 01, 2017 at 06:06:23PM +, Charles Hedrick wrote: > > My problem with KfW is more serious: I can’t get putty to see the tickets. > That makes it of no real use to me. I’m going to try installing Ubuntu on > Windows. I was able to reliably get putty working with GSSAPI/Kerberos when I was working on KfW. The putty settings were kind of buried, though. I guess https://www.pdc.kth.se/resources/software/login-1/windows/putty suggests that Connection-->SSH-->Auth-->GSSAPI is where the checkboxes are hiding, though there may have been one other thing that needed tweaking. Hope this helps, Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
You could issue a machine-specific key table, and then use a script that does kinit from the key table, then kinit -T pointing to the resulting credentials cache. I have verified the KfW kinit -T works. We use OTP on Linux. I can’t get FAST/PKINIT to work there either. I have a kerberized service (using the machine’s key table) that will generate a credentials cache on a server and return it. That’s used to bootstrap kinit -T. Surely there was a better approach than getting X509 involved in kerberos. I look forward to any alternatives. My problem with KfW is more serious: I can’t get putty to see the tickets. That makes it of no real use to me. I’m going to try installing Ubuntu on Windows. > On Oct 30, 2017, at 5:25 AM, Oleksandr Yermolenko wrote: > > Hi all, > > I'm trying to configure a Windows 7 workstation to do OTP preauth. > > I've installed MIT Kerberos for Windows 4.1, put krb5.ini as for linux > and ... of course obtain the error "Generic preauthentication > failure". FAST/PKINIT anonymous unsupported ... > > any ideas how to implement OTP for Windows with MIT kerberos client? > possible? > > thanks a lot for your help > > Oleksandr Yermolenko > > I can use without any problem on the systems Debian/CentOS based > according to [1] and [2] > > [1] > https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.eyrie.org%2F~eagle%2Fsoftware%2Fpam-krb5%2Fpam-krb5.html&data=02%7C01%7Chedrick%40rutgers.edu%7C9d7e7243d2584751e24f08d51f789b14%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636449525221981239&sdata=YBF9PR3Pb9Hp7E2JewIVBH7%2B2OKCVWmrUpShS5jVgrI%3D&reserved=0 > [2] > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.mit.edu%2Fpipermail%2Fkerberos%2F2017-July%2F021747.html&data=02%7C01%7Chedrick%40rutgers.edu%7C9d7e7243d2584751e24f08d51f789b14%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636449525221981239&sdata=%2BW5z617hkF39IGa29zFBAJj7JJWKGFnBQG891F7ZNb0%3D&reserved=0 > > Kerberos mailing list Kerberos@mit.edu > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=02%7C01%7Chedrick%40rutgers.edu%7C9d7e7243d2584751e24f08d51f789b14%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636449525221981239&sdata=U%2BlGLzBr0hX5ZZisc%2Frb2CK%2FRxs34kj%2BBdo0gbJZxUk%3D&reserved=0 Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
On Mon, Oct 30, 2017 at 9:11 PM, Benjamin Kaduk wrote: > On Mon, Oct 30, 2017 at 09:05:10AM -0700, Pallissard, Matthew wrote: > > > any ideas how to implement OTP for Windows with MIT kerberos client? > possible? > > > > I don't know if KFW 4.1 supports OTP but what I do know is that in the > past I couldn't get PKINIT working with KFW. I had to implement heimdal on > the client end. > > > > https://www.mail-archive.com/kfwdev@mit.edu/msg00822.html > > > > Could be related. Someone here could probably speak to that better than > myself though. > > It's quite related, yes. > > The FAST OTP mechanism of RFC 6560 requires a FAST tunnel to exist over > which the OTP value is sent. Generally this tunnel is obtained via > anonymous PKINIT, but PKINIT of all forms is not currently implemented > in KfW. In principle, the needed FAST tunnel could be obtained in > other ways, e.g., via a machine keytab, but the number of situations > in which these other methods would actually be useful are quite limited. > This is why moving to SPAKE will make OTP easier to accomplish and support with KfW. > > -Ben > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > > -- Thank you, Dmitri Pal Engineering Director, Identity Management and Platform Security Red Hat, Inc. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
On Mon, 30 Oct 2017 09:05:10 -0700 "Pallissard, Matthew" wrote: > > any ideas how to implement OTP for Windows with MIT kerberos > > client? possible? > > I don't know if KFW 4.1 supports OTP but what I do know is that in > the past I couldn't get PKINIT working with KFW. I had to implement > heimdal on the client end. Matt, have yo managed to setup anonymous FAST/PKINIT tunnel using heimdal as windows client? just want to clarify. Oleksandr Yermolenko > > https://www.mail-archive.com/kfwdev@mit.edu/msg00822.html > > Could be related. Someone here could probably speak to that better > than myself though. > > > Matt Pallissard > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
thanks for your notes and direction Oleksandr Yermolenko On Mon, 30 Oct 2017 20:11:25 -0500 Benjamin Kaduk wrote: > On Mon, Oct 30, 2017 at 09:05:10AM -0700, Pallissard, Matthew wrote: > > > any ideas how to implement OTP for Windows with MIT kerberos > > > client? possible? > > > > I don't know if KFW 4.1 supports OTP but what I do know is that in > > the past I couldn't get PKINIT working with KFW. I had to implement > > heimdal on the client end. > > > > https://www.mail-archive.com/kfwdev@mit.edu/msg00822.html > > > > Could be related. Someone here could probably speak to that better > > than myself though. > > It's quite related, yes. > > The FAST OTP mechanism of RFC 6560 requires a FAST tunnel to exist > over which the OTP value is sent. Generally this tunnel is obtained > via anonymous PKINIT, but PKINIT of all forms is not currently > implemented in KfW. In principle, the needed FAST tunnel could be > obtained in other ways, e.g., via a machine keytab, but the number of > situations in which these other methods would actually be useful are > quite limited. > > -Ben > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
On Mon, Oct 30, 2017 at 09:05:10AM -0700, Pallissard, Matthew wrote: > > any ideas how to implement OTP for Windows with MIT kerberos client? > > possible? > > I don't know if KFW 4.1 supports OTP but what I do know is that in the past I > couldn't get PKINIT working with KFW. I had to implement heimdal on the > client end. > > https://www.mail-archive.com/kfwdev@mit.edu/msg00822.html > > Could be related. Someone here could probably speak to that better than > myself though. It's quite related, yes. The FAST OTP mechanism of RFC 6560 requires a FAST tunnel to exist over which the OTP value is sent. Generally this tunnel is obtained via anonymous PKINIT, but PKINIT of all forms is not currently implemented in KfW. In principle, the needed FAST tunnel could be obtained in other ways, e.g., via a machine keytab, but the number of situations in which these other methods would actually be useful are quite limited. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos OTP with Windows
> any ideas how to implement OTP for Windows with MIT kerberos client? possible? I don't know if KFW 4.1 supports OTP but what I do know is that in the past I couldn't get PKINIT working with KFW. I had to implement heimdal on the client end. https://www.mail-archive.com/kfwdev@mit.edu/msg00822.html Could be related. Someone here could probably speak to that better than myself though. Matt Pallissard Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
MIT Kerberos OTP with Windows
Hi all, I'm trying to configure a Windows 7 workstation to do OTP preauth. I've installed MIT Kerberos for Windows 4.1, put krb5.ini as for linux and ... of course obtain the error "Generic preauthentication failure". FAST/PKINIT anonymous unsupported ... any ideas how to implement OTP for Windows with MIT kerberos client? possible? thanks a lot for your help Oleksandr Yermolenko I can use without any problem on the systems Debian/CentOS based according to [1] and [2] [1] https://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html [2] http://mailman.mit.edu/pipermail/kerberos/2017-July/021747.html Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Can I automatically cache AD tickets into a file on windows?
Perfect! I'll give it a shot to see if it works in my case. Thanks! -Original Message- From: Benjamin Kaduk [mailto:ka...@mit.edu] Sent: Sunday, November 20, 2016 4:13 PM To: Mauro Cazzari Cc: Todd Grayson ; Kerberos@mit.edu Subject: Re: Can I automatically cache AD tickets into a file on windows? On Fri, Nov 18, 2016 at 04:51:03PM +, Mauro Cazzari wrote: > One more thing: if MIT Kerberos is installed, is there a way to populate the > KRB5CCNAME cache file automatically when I log on to Windows without having > to use a keytab or having to run a kinit under the covers? MIT KfW does include a utility "ms2mit.exe" that attempts to export kerberos credentials from the Windows LSA to a KfW credentials cache (which by default will be an API: cache but can be configured to be a FILE: cache). However, those attempts will fail in some situations, such as when the user is a local administrator, on recent versions of Windows. Some sites have run ms2mit during the login process to get that sort of behavior; however, in the KfW 4.1 series, the LSA: support is improved and it may be feasible to just use the LSA: cache directly. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Can I automatically cache AD tickets into a file on windows?
On Fri, Nov 18, 2016 at 04:51:03PM +, Mauro Cazzari wrote: > One more thing: if MIT Kerberos is installed, is there a way to populate the > KRB5CCNAME cache file automatically when I log on to Windows without having > to use a keytab or having to run a kinit under the covers? MIT KfW does include a utility "ms2mit.exe" that attempts to export kerberos credentials from the Windows LSA to a KfW credentials cache (which by default will be an API: cache but can be configured to be a FILE: cache). However, those attempts will fail in some situations, such as when the user is a local administrator, on recent versions of Windows. Some sites have run ms2mit during the login process to get that sort of behavior; however, in the KfW 4.1 series, the LSA: support is improved and it may be feasible to just use the LSA: cache directly. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Can I automatically cache AD tickets into a file on windows?
You might be able to do some sort of powershell script? I don't think the KFW has a startup context to it. The thin is you would need to pass credentials in somehow which starts to weaken the integrity of the security model once you start caching passwords/keytabs. We should know, Hadoop is the poster child of poor credential handling (and a ton of work is going into cleaning that all up). On Friday, November 18, 2016, Mauro Cazzari wrote: > One more thing: if MIT Kerberos is installed, is there a way to populate > the KRB5CCNAME cache file automatically when I log on to Windows without > having to use a keytab or having to run a kinit under the covers? > > > > *From:* Todd Grayson [mailto:tgray...@cloudera.com > ] > *Sent:* Friday, November 18, 2016 11:34 AM > *To:* Mauro Cazzari > > *Cc:* Kerberos@mit.edu > *Subject:* Re: Can I automatically cache AD tickets into a file on > windows? > > > > From what I understand, the windows SSPI implementation does not provide a > facility to hold the credentials in a file. You would use the MIT KFW to > be able to do that. > > On Friday, November 18, 2016, Mauro Cazzari > wrote: > > Kerberos experts, > Is there a way to automatically cache AD-generated tickets to the file > provided through the KRB5CCNAME environment variable on Windows without > having to run a kinit? My understanding is that Windows caches tickets in > memory (whereas Unix does the same on file). Do I need to install MIT > Kerberos, or (ideally) can I just use the copy of Kerberos that comes with > Windows to achieve my goal? > Thanks! > Mauro. > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > -- > > Todd Grayson > > Business Operations Manager > > Customer Operations Engineering > > Security SME > > > -- Todd Grayson Business Operations Manager Customer Operations Engineering Security SME Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Can I automatically cache AD tickets into a file on windows?
One more thing: if MIT Kerberos is installed, is there a way to populate the KRB5CCNAME cache file automatically when I log on to Windows without having to use a keytab or having to run a kinit under the covers? From: Todd Grayson [mailto:tgray...@cloudera.com] Sent: Friday, November 18, 2016 11:34 AM To: Mauro Cazzari Cc: Kerberos@mit.edu Subject: Re: Can I automatically cache AD tickets into a file on windows? >From what I understand, the windows SSPI implementation does not provide a >facility to hold the credentials in a file. You would use the MIT KFW to be >able to do that. On Friday, November 18, 2016, Mauro Cazzari mailto:mauro.cazz...@sas.com>> wrote: Kerberos experts, Is there a way to automatically cache AD-generated tickets to the file provided through the KRB5CCNAME environment variable on Windows without having to run a kinit? My understanding is that Windows caches tickets in memory (whereas Unix does the same on file). Do I need to install MIT Kerberos, or (ideally) can I just use the copy of Kerberos that comes with Windows to achieve my goal? Thanks! Mauro. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos -- Todd Grayson Business Operations Manager Customer Operations Engineering Security SME [http://files.cloudera.com.s3.amazonaws.com/New%20Branding/cloudera-small.png] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Can I automatically cache AD tickets into a file on windows?
Thanks Todd. I was thinking the same thing, but I just wasn’t sure. From: Todd Grayson [mailto:tgray...@cloudera.com] Sent: Friday, November 18, 2016 11:34 AM To: Mauro Cazzari Cc: Kerberos@mit.edu Subject: Re: Can I automatically cache AD tickets into a file on windows? From what I understand, the windows SSPI implementation does not provide a facility to hold the credentials in a file. You would use the MIT KFW to be able to do that. On Friday, November 18, 2016, Mauro Cazzari mailto:mauro.cazz...@sas.com>> wrote: Kerberos experts, Is there a way to automatically cache AD-generated tickets to the file provided through the KRB5CCNAME environment variable on Windows without having to run a kinit? My understanding is that Windows caches tickets in memory (whereas Unix does the same on file). Do I need to install MIT Kerberos, or (ideally) can I just use the copy of Kerberos that comes with Windows to achieve my goal? Thanks! Mauro. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos -- Todd Grayson Business Operations Manager Customer Operations Engineering Security SME [http://files.cloudera.com.s3.amazonaws.com/New%20Branding/cloudera-small.png] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Can I automatically cache AD tickets into a file on windows?
>From what I understand, the windows SSPI implementation does not provide a facility to hold the credentials in a file. You would use the MIT KFW to be able to do that. On Friday, November 18, 2016, Mauro Cazzari wrote: > Kerberos experts, > Is there a way to automatically cache AD-generated tickets to the file > provided through the KRB5CCNAME environment variable on Windows without > having to run a kinit? My understanding is that Windows caches tickets in > memory (whereas Unix does the same on file). Do I need to install MIT > Kerberos, or (ideally) can I just use the copy of Kerberos that comes with > Windows to achieve my goal? > Thanks! > Mauro. > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > -- Todd Grayson Business Operations Manager Customer Operations Engineering Security SME Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Can I automatically cache AD tickets into a file on windows?
Kerberos experts, Is there a way to automatically cache AD-generated tickets to the file provided through the KRB5CCNAME environment variable on Windows without having to run a kinit? My understanding is that Windows caches tickets in memory (whereas Unix does the same on file). Do I need to install MIT Kerberos, or (ideally) can I just use the copy of Kerberos that comes with Windows to achieve my goal? Thanks! Mauro. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: mit kdc windows client silent install
On Fri, Nov 11, 2016 at 03:25:03AM +, Edward Gleeck wrote:
> Thanks Todd. I'll give this a shot. It'll be good from an automation
> perspective to be able to pass in parameters such as krb5.conf file and the
> cache locations, etc. But these all could be tied in to a power shell
> script so it should be good.
msiexec /quiet should work fine, yes.
Even in interactive mode there's no way to control the krb5.conf file (which
can affect default ccache locations). There is a registry entry that can
force the path to krb5.conf (which, since the registry entry specifies the
full path, does not need to be named krb5.conf), though, FWIW. Only
the KRB5_CONFIG environment variable has higher precedence than
{HKCU,HKLM}\Software\MIT\Kerberos5\config
-Ben
> On Thu, Nov 10, 2016 at 10:03 PM Todd Grayson wrote:
>
> > I've used this in the past (not with kfw tho)... given its an MSI
> > installer this should work...
> >
> >
> > http://stackoverflow.com/questions/8560166/silent-installation-of-a-msi-package
> >
> > (assuming the kfw install package from here)
> >
> > http://web.mit.edu/kerberos/dist/#krb5-1.14
> >
> > On Thu, Nov 10, 2016 at 7:53 PM, Edward Gleeck wrote:
> >
> > Does windows mit kdc client support silent/unattended install?
> >
> > On the release notes there are some documentation on building an installer
> > which is quite involved, so I was wondering if the currently installer
> > supports any install parameters.
> >
> > Thanks,
> > Ed
> >
> >
> > Kerberos mailing list Kerberos@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
> >
> >
> > --
> > Todd Grayson
> > Business Operations Manager
> > Customer Operations Engineering
> > Security SME
> >
> > --
> Sent from handheld device
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: mit kdc windows client silent install
Thanks Todd. I'll give this a shot. It'll be good from an automation perspective to be able to pass in parameters such as krb5.conf file and the cache locations, etc. But these all could be tied in to a power shell script so it should be good. On Thu, Nov 10, 2016 at 10:03 PM Todd Grayson wrote: > I've used this in the past (not with kfw tho)... given its an MSI > installer this should work... > > > http://stackoverflow.com/questions/8560166/silent-installation-of-a-msi-package > > (assuming the kfw install package from here) > > http://web.mit.edu/kerberos/dist/#krb5-1.14 > > On Thu, Nov 10, 2016 at 7:53 PM, Edward Gleeck wrote: > > Does windows mit kdc client support silent/unattended install? > > On the release notes there are some documentation on building an installer > which is quite involved, so I was wondering if the currently installer > supports any install parameters. > > Thanks, > Ed > > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > -- > Todd Grayson > Business Operations Manager > Customer Operations Engineering > Security SME > > -- Sent from handheld device Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: mit kdc windows client silent install
I've used this in the past (not with kfw tho)... given its an MSI installer this should work... http://stackoverflow.com/questions/8560166/silent-installation-of-a-msi-package (assuming the kfw install package from here) http://web.mit.edu/kerberos/dist/#krb5-1.14 On Thu, Nov 10, 2016 at 7:53 PM, Edward Gleeck wrote: > Does windows mit kdc client support silent/unattended install? > > On the release notes there are some documentation on building an installer > which is quite involved, so I was wondering if the currently installer > supports any install parameters. > > Thanks, > Ed > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > -- Todd Grayson Business Operations Manager Customer Operations Engineering Security SME Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
mit kdc windows client silent install
Does windows mit kdc client support silent/unattended install? On the release notes there are some documentation on building an installer which is quite involved, so I was wondering if the currently installer supports any install parameters. Thanks, Ed Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Regarding the software MIT Kerberos for Windows version 4.1
[Dropped krbdev from the CC list; please don't copy it on replies to this thread.] "Kumar, Ashish /CS" writes: > Hello Team, Please note this is a public Kerberos community support forum, not a private team contact point. The MIT Kerberos Team does not generally provide private customer support to external parties. I will, however, try to point you toward readily available information that should help you with your request. > I am contacting you on behalf of ExxonMobil IT Asset Management regarding > your software called MIT Kerberos for Windows version 4.1 > > > > --> In order to proceed with a request raised by one of our affiliates, > please provide your most recent End User License Agreement (EULA) and confirm > if it covers all of the software products marketed by your company or if it > is specific to a certain product line. EULA is probably not the applicable term for our software. The copyright license statements for the MIT Kerberos software (which includes the Kerberos for Windows product) are available at http://web.mit.edu/kerberos/krb5-latest/doc/mitK5license.html and in the NOTICE file contained in the source code distribution files (e.g., kfw-4.1-src.zip for MIT Kerberos for Windows 4.1). > --> Could you please provide me the list of third party components used in > this software? See the license page or the NOTICE file. > --> Could you please provide me information that is this freeware or not? > Also please provide me the information that if the source code is available > or not. See the license page or the NOTICE file. > --> If you have already classified this software with ECCN, please confirm > the applicable number. We do not publicly state an applicable ECCN for this software at this time. Any information that we do make available about export law that may apply to our software is for general background purposes only and does not constitute legal advice. You (or your legal counsel) should make your own determination of the applicable ECCN. Please see the export law warnings at the top of http://web.mit.edu/kerberos/dist/index.html > If you do not have your software classified with an ECCN, please kindly > answer the following questions so that we may self-assess: The answers to your ECCN self-assesment questions are available in the documentation and source code. > 1, Does the Software perform any encryption or utilize any encryption > processes? Y/N > > 2. If the answer is YES to question 1, please indicate if the encryption is > coded into the application or separately called (such as using SSL) > > 3. If the answer is YES to question 1, please indicate what function(s) the > cryptography/encryption serves > > > > A, Copyright protection purposes (Includes using a license key/code) > > B, User authentication purposes > > C, A core part of the functionality such as to encrypt databases > > D, To encrypt communications between the software and a host system. > > > > Background information: > > An Export Control Classification Number (ECCN) is a specific alpha-numeric > code that identifies the level of export control for items e.g. software that > are exported from member states of the Wassenaar Arrangement, including the > United States. After obtaining the ECCN, the exporter must determine whether > an export license is required to export items to certain countries. > > > Thank you in advance for your cooperation! > > > Thanks and Regards, > Ashish Kumar > New Products-Software Analyst > EMIT Customer Infrastructure > > HCL Technologies Private Limited > (CIN: L74140DL1991PLC046369) > 10th Floor, ODC-IV, Software Tower 6, Sector 126 > Noida SEZ, Uttar Pradesh - 201301, India > Phone +14088093746; Extn - 4144550 > IM me | E-mail > me<mailto:ashish.ku...@em-msph.com> > > for > > ExxonMobil Global Services Company > 22777 Springwoods Village Parkway > Spring, TX 77389 > United States of America > > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Regarding the software MIT Kerberos for Windows version 4.1
Hello Team, I am contacting you on behalf of ExxonMobil IT Asset Management regarding your software called MIT Kerberos for Windows version 4.1 --> In order to proceed with a request raised by one of our affiliates, please provide your most recent End User License Agreement (EULA) and confirm if it covers all of the software products marketed by your company or if it is specific to a certain product line. --> Could you please provide me the list of third party components used in this software? --> Could you please provide me information that is this freeware or not? Also please provide me the information that if the source code is available or not. --> If you have already classified this software with ECCN, please confirm the applicable number. If you do not have your software classified with an ECCN, please kindly answer the following questions so that we may self-assess: 1, Does the Software perform any encryption or utilize any encryption processes? Y/N 2. If the answer is YES to question 1, please indicate if the encryption is coded into the application or separately called (such as using SSL) 3. If the answer is YES to question 1, please indicate what function(s) the cryptography/encryption serves A, Copyright protection purposes (Includes using a license key/code) B, User authentication purposes C, A core part of the functionality such as to encrypt databases D, To encrypt communications between the software and a host system. Background information: An Export Control Classification Number (ECCN) is a specific alpha-numeric code that identifies the level of export control for items e.g. software that are exported from member states of the Wassenaar Arrangement, including the United States. After obtaining the ECCN, the exporter must determine whether an export license is required to export items to certain countries. Thank you in advance for your cooperation! Thanks and Regards, Ashish Kumar New Products-Software Analyst EMIT Customer Infrastructure HCL Technologies Private Limited (CIN: L74140DL1991PLC046369) 10th Floor, ODC-IV, Software Tower 6, Sector 126 Noida SEZ, Uttar Pradesh - 201301, India Phone +14088093746; Extn - 4144550 IM me | E-mail me<mailto:ashish.ku...@em-msph.com> for ExxonMobil Global Services Company 22777 Springwoods Village Parkway Spring, TX 77389 United States of America Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Searching a debugging tool for kerberos inside Windows 10 Desktop
Hi! Dear Colleagues, I'm taking my first steps in using kerberos, our goal is to authenticate users who wish to use their Windows desktops via FreeIPA. The issue is that we have done both FreeIPA configuration as in the windows client, but every time I try to use my credentials that exist in FreeIPA, I see an error message in windows logs indicating: The Security System detected an authentication error for the server DNS/ds1.bbr.cl. The failure code from authentication protocol Kerberos was "No authority could be contacted for authentication. (0x80090311)". The kerberos configuration inside the windows desktop is: C:\Windows\system32>ksetup default realm = BBR.CL (external) BBR.CL: kdc = testwin10.areaprod.b2b kpasswd = testwin10.areaprod.b2b Realm Flags = 0x0No Realm Flags Mapping all users (*) to a local account by the same name (*). C:\Windows\system32> the KDC is tha same desktop.. is ok? or there is a mistake? I don't know how i can to do debug, for detect the bug in the configuration.., searching by google, i can to find the following project: http://blog.michelbarneveld.nl/michel/archive/2009/12/05/kerberos-authentication-tester.aspx Is very nice the tool, but i need one for debug the authentication using kerberos againts to freeipa server, no http server..., also i tryed to usehttps://support.microsoft.com/en-us/kb/262177, but without success in my desktop windows 10. Thanks in advance, if you have any hint for this.. -Pablo ps: FreeIPa Server configuration for Kerberoshttps://www.freeipa.org/page/Windows_authentication_against_FreeIPA Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Windows 2012R2 & MIT Kerberos Trust / SSO
There are ways to sync the AD server with the KDC, so in effect they are separate but equal. On Aug 20, 2016 12:14 PM, "Darren Terry" wrote: List, I am currently working on a project where I am required to integrate a Windows 2012R2 domain with an existing Kerberos realm. The domain has not been built yet so I have the luxury of having no technical debt to deal with, I get a fresh start on the Windows side. Does anyone have experience with this? What path did you take? Any guidance you could provide would be appreciated. Thanks! Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Windows 2012R2 & MIT Kerberos Trust / SSO
List, I am currently working on a project where I am required to integrate a Windows 2012R2 domain with an existing Kerberos realm. The domain has not been built yet so I have the luxury of having no technical debt to deal with, I get a fresh start on the Windows side. Does anyone have experience with this? What path did you take? Any guidance you could provide would be appreciated. Thanks! Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
MIT kerberos windows
Hi, I have a colleague who followed the same procedure as we normally use to install and setup the MIT kerberkos windows client but he gets the following error when he enters his credentials: Ticket initialization failed. Kerberos 5: invalid argument (error 22) I could not find any details about this error. Could you suggest a cause or a fix for this error? The procedure we follow on windows 7 64 bits is: 1. Get the krb5.ini file in "c:\ProgramData\MIT\Kerberos5\" 2. Set the windows environment variable "KRB5CCNAME" to "C:\Users\username\krb5cc_username" 3. Run the MIT Kerberos ticket manager 4. Get ticket / enter the principal and corresponding password Thanks Damien Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Forwardable TGT - Windows vs MIT behavior?
On Sat, Apr 23, 2016 at 09:47:59AM -0700, Ray Van Dolson wrote: > On Sat, Apr 23, 2016 at 09:41:47AM -0700, Ray Van Dolson wrote: > > Using PuTTY from a domain-joined Windows 7 machine, with that machine's > > PuTTY stack configured to allow credential delegation and connecting to > > a RHEL7 server, also joined to AD but *not* configured in AD to be > > trusted for delegation, I do not get a TGT added to my cache when I > > connect. > > > > However, if I use MIT Kerberos on the Windows side to obtain the ticket > > and then configure PuTTY to prefer MIT over MS SPI, and connect to the > > same RHEL7 machine, I *do* get a forwarded TGT (klist -f: Flags: FfPRA) > > > > PuTTY w/ MS SSPI works *if* I go into AD and set the target server up > > to be configured for delegation trust. > > > > Can someone explain the difference in behavior? Almost feels like the > > ticket the MIT stack is providing to PuTTY is different than the MS > > stack's ticket. > > > > I also see this alluded to elsewhere[1]. > > > > Thanks, > > Ray > > Apologies for self-reply, but perhaps this is the reason? > > http://mailman.mit.edu/pipermail/kerberos/2014-February/019500.html > > Ray Should have kept my search up. Looks like that thread revives a couple of months later and fully explains things: http://mailman.mit.edu/pipermail/kerberos/2014-April/019805.html Sorry for the noise. Ray Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Forwardable TGT - Windows vs MIT behavior?
On Sat, Apr 23, 2016 at 09:41:47AM -0700, Ray Van Dolson wrote: > Using PuTTY from a domain-joined Windows 7 machine, with that machine's > PuTTY stack configured to allow credential delegation and connecting to > a RHEL7 server, also joined to AD but *not* configured in AD to be > trusted for delegation, I do not get a TGT added to my cache when I > connect. > > However, if I use MIT Kerberos on the Windows side to obtain the ticket > and then configure PuTTY to prefer MIT over MS SPI, and connect to the > same RHEL7 machine, I *do* get a forwarded TGT (klist -f: Flags: FfPRA) > > PuTTY w/ MS SSPI works *if* I go into AD and set the target server up > to be configured for delegation trust. > > Can someone explain the difference in behavior? Almost feels like the > ticket the MIT stack is providing to PuTTY is different than the MS > stack's ticket. > > I also see this alluded to elsewhere[1]. > > Thanks, > Ray Apologies for self-reply, but perhaps this is the reason? http://mailman.mit.edu/pipermail/kerberos/2014-February/019500.html Ray Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Forwardable TGT - Windows vs MIT behavior?
Using PuTTY from a domain-joined Windows 7 machine, with that machine's PuTTY stack configured to allow credential delegation and connecting to a RHEL7 server, also joined to AD but *not* configured in AD to be trusted for delegation, I do not get a TGT added to my cache when I connect. However, if I use MIT Kerberos on the Windows side to obtain the ticket and then configure PuTTY to prefer MIT over MS SPI, and connect to the same RHEL7 machine, I *do* get a forwarded TGT (klist -f: Flags: FfPRA) PuTTY w/ MS SSPI works *if* I go into AD and set the target server up to be configured for delegation trust. Can someone explain the difference in behavior? Almost feels like the ticket the MIT stack is providing to PuTTY is different than the MS stack's ticket. I also see this alluded to elsewhere[1]. Thanks, Ray [1] http://serverfault.com/questions/646854/putty-kerberos-gssapi-authentication/705889#705889 Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Does Kerberos works with Windows 2012 & AES256 bit
Thanks Ross! Much appreciated. --Prashanth My iPhone > On Feb 3, 2016, at 4:35 AM, Wilper, Ross wrote: > > Windows Server 2012 supports AES enctypes: > > AES128_CTS_HMAC_SHA1_96 > AES256_CTS_HMAC_SHA1_96 > > -Ross > > -Original Message- > From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of > Prashanth > Sent: Tuesday, February 2, 2016 12:18 PM > To: kerberos@mit.edu > Subject: Does Kerberos works with Windows 2012 & AES256 bit > > Hi, > > Quick question guys.. > > I am pretty much new this. > > Hence, I would like to know whether or not Kerberos works with Windows 2012 > and AES256 bit encryption. > > Your help is much appreciated. > > Thanks, > Prashanth > > My iPhone > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Does Kerberos works with Windows 2012 & AES256 bit
Windows Server 2012 supports AES enctypes: AES128_CTS_HMAC_SHA1_96 AES256_CTS_HMAC_SHA1_96 -Ross -Original Message- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Prashanth Sent: Tuesday, February 2, 2016 12:18 PM To: kerberos@mit.edu Subject: Does Kerberos works with Windows 2012 & AES256 bit Hi, Quick question guys.. I am pretty much new this. Hence, I would like to know whether or not Kerberos works with Windows 2012 and AES256 bit encryption. Your help is much appreciated. Thanks, Prashanth My iPhone Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Does Kerberos works with Windows 2012 & AES256 bit
Hi, Quick question guys.. I am pretty much new this. Hence, I would like to know whether or not Kerberos works with Windows 2012 and AES256 bit encryption. Your help is much appreciated. Thanks, Prashanth My iPhone Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
klist from windows does not show tickets for gsskrb5.dll
Hello dear list, I'm sorry, my question is not directly related to MIT Kerberos, but maybe someone can help me?! We uses Kerberos SSO for SAP under Windows 7, joined in a AD domain. For Windows 7 Clients who are not member of a AD domain, we use the MIT Kerberos client. Every thing in both constellations works fine. The gssapi used by the SAP Clients with joined Windows 7 WS is gsskrb5.dll. This can be found under http://www.kerberos.org/software/samples/gsskrb5/ As far I understood, the gsskrb5.dll uses the sspi from Windows as ticket cache. But if I use klist, I can't see any ticket for the SAP-Service. Does anyone know why? I only want know this for debugging reasons. Thanks Mike Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
MIT Kerberos for windows 4.01 title bar dissapears after running for a few days
This usually happens between 3 or 4 days of continuous operation. Suddenly the title bar disappears and you can't close it by clicking the now missing X button. [cid:image001.png@01D14EE0.24DD0380] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: issues getting kerberos ticket with Windows Server 2012
You may want to try the solution from serverfault: http://serverfault.com/questions/441662/kdc-has-no-support-for-encryption-type-when-setting-up-cross-realm-trust-betwe -Original Message- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Rishi Danny Kanhaising Sent: Wednesday, November 25, 2015 11:31 PM To: kerberos@mit.edu Subject: issues getting kerberos ticket with Windows Server 2012 Sorry for my bad english. For a school project I am implementing kerberos with active directory. To finish this project I have to fix the next error: "KDC has no support for padata type". How can I fix this error ? Regards, Rishi Kerberos mailing list Kerberos@mit.edu https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.mit.edu_mailman_listinfo_kerberos&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=ISuq9iiWmSJqQXtGmp29Ng&m=42OnbAQA6aXtq0ECwqIi316lLhREEOMXe1CQKMpYD8o&s=dFRikyBACnl3M3AgpHUCNDsgsobR7-z00LokiKXl4ZQ&e= Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
issues getting kerberos ticket with Windows Server 2012
Sorry for my bad english. For a school project I am implementing kerberos with active directory. To finish this project I have to fix the next error: "KDC has no support for padata type". How can I fix this error ? Regards, Rishi Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Windows
I noticed that I made a minor mistake when I typed the key, it should read: HKEY_CURRENT_USER\SOFTWARE\MIT\MIT Kerberos\Settings Randy Randy Morgan CSR Department of Chemistry and Biochemistry Brigham Young University 801-422-4100 On 11/18/2015 7:14 PM, Benjamin Kaduk wrote: > On Wed, 18 Nov 2015, Randolph Morgan wrote: > >> I found the answer to my question, so I thought I would share it with others >> here on the list. To get Windows to acknowledge that a ticket has been >> issued > Thank you for following up! > >> through MIT Kerberos KfW 4.0.1 you need to edit a registry key. The key is >> located at: HKEY_CURRENT_USER\SOFTWARE\MIT Kerberos\Settings. Click on >> Issued >> and change the value from 0 to 1. Once I did this a klist now shows the >> ticket issued by KfW 4.0.1. > That said, I do not believe this corresponds to the behavior change you > are describing -- that registry entry controls whether the display column > for the time the given ticket was issued is present in the MIT > Kerberos.exe Ticket Manager application (and the corresponding state of > the checkbox for toggling that view column). > > > > -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Windows
On Wed, 18 Nov 2015, Randolph Morgan wrote: > I found the answer to my question, so I thought I would share it with others > here on the list. To get Windows to acknowledge that a ticket has been issued Thank you for following up! > through MIT Kerberos KfW 4.0.1 you need to edit a registry key. The key is > located at: HKEY_CURRENT_USER\SOFTWARE\MIT Kerberos\Settings. Click on Issued > and change the value from 0 to 1. Once I did this a klist now shows the > ticket issued by KfW 4.0.1. That said, I do not believe this corresponds to the behavior change you are describing -- that registry entry controls whether the display column for the time the given ticket was issued is present in the MIT Kerberos.exe Ticket Manager application (and the corresponding state of the checkbox for toggling that view column). -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Windows
I found the answer to my question, so I thought I would share it with others here on the list. To get Windows to acknowledge that a ticket has been issued through MIT Kerberos KfW 4.0.1 you need to edit a registry key. The key is located at: HKEY_CURRENT_USER\SOFTWARE\MIT Kerberos\Settings. Click on Issued and change the value from 0 to 1. Once I did this a klist now shows the ticket issued by KfW 4.0.1. Randy Randy Morgan CSR Department of Chemistry and Biochemistry Brigham Young University 801-422-4100 On 11/16/2015 8:01 PM, Benjamin Kaduk wrote: > On Mon, 16 Nov 2015, Randolph Morgan wrote: > >> I have installed MIT Kerberos 4.0.1 on a Windows 10 machine. Everything >> I have read indicates that the identity manager is not integrated into >> the new ticket manager. Ticket manager shows that I have received a > I'm not sure what you mean by these terms. Is "the identity manager" the > "Network Identity Manager" such as is available from > https://www.secure-endpoints.com/netidmgr/v2/ ? Is the "new ticket > manager" the "MIT Kerberos.exe" distributed in the KfW 4.0.1 installer? > >> ticket from my krbtgt from my server, but Windows does not show a ticket >> when I run klist. If I run kinit, Windows receives and the ticket > There is a klist.exe shipped with Windows by Microsoft, that is unrelated > to either of the previously mentioned programs. (You can get the KfW > klist.exe by specifying a full path, e.g., C:\Program > Files\MIT\Kerberos\bin\klist.exe) > >> manager shows a ticket, but if I go through the ticket manager Windows >> does not show a valid ticket. is there some kind of registry setting >> that I need to modify, or is there something in my krb5.ini file that I >> should modify so that windows shows a ticket when it is issued through >> the ticket manager? > It sounds like perhaps (but it's very hard to tell since the description > lacks sufficient detail) you are putting credentials into different caches > when obtained via the command-line and via the MIT Kerberos.exe Ticket > Manager. The KfW klist.exe with the -A argument should help clarify > whether this is the case. Only the MSLSA: cache is accessible to the > Microsoft Kerberos implementation. > > The MIT Kerberos.exe Ticket Manager does have a "make default" > functionality that will set a registry key for future credential > acquisitions. > > -Ben Kaduk Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Windows
On Mon, 16 Nov 2015, Randolph Morgan wrote: > I have installed MIT Kerberos 4.0.1 on a Windows 10 machine. Everything > I have read indicates that the identity manager is not integrated into > the new ticket manager. Ticket manager shows that I have received a I'm not sure what you mean by these terms. Is "the identity manager" the "Network Identity Manager" such as is available from https://www.secure-endpoints.com/netidmgr/v2/ ? Is the "new ticket manager" the "MIT Kerberos.exe" distributed in the KfW 4.0.1 installer? > ticket from my krbtgt from my server, but Windows does not show a ticket > when I run klist. If I run kinit, Windows receives and the ticket There is a klist.exe shipped with Windows by Microsoft, that is unrelated to either of the previously mentioned programs. (You can get the KfW klist.exe by specifying a full path, e.g., C:\Program Files\MIT\Kerberos\bin\klist.exe) > manager shows a ticket, but if I go through the ticket manager Windows > does not show a valid ticket. is there some kind of registry setting > that I need to modify, or is there something in my krb5.ini file that I > should modify so that windows shows a ticket when it is issued through > the ticket manager? It sounds like perhaps (but it's very hard to tell since the description lacks sufficient detail) you are putting credentials into different caches when obtained via the command-line and via the MIT Kerberos.exe Ticket Manager. The KfW klist.exe with the -A argument should help clarify whether this is the case. Only the MSLSA: cache is accessible to the Microsoft Kerberos implementation. The MIT Kerberos.exe Ticket Manager does have a "make default" functionality that will set a registry key for future credential acquisitions. -Ben Kaduk Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Windows
I have installed MIT Kerberos 4.0.1 on a Windows 10 machine. Everything I have read indicates that the identity manager is not integrated into the new ticket manager. Ticket manager shows that I have received a ticket from my krbtgt from my server, but Windows does not show a ticket when I run klist. If I run kinit, Windows receives and the ticket manager shows a ticket, but if I go through the ticket manager Windows does not show a valid ticket. is there some kind of registry setting that I need to modify, or is there something in my krb5.ini file that I should modify so that windows shows a ticket when it is issued through the ticket manager? Randy -- Randy Morgan CSR Department of Chemistry and Biochemistry Brigham Young University 801-422-4100 Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos, Windows and FreeIPA
On 10/23/2015 02:58 PM, Randolph Morgan wrote: > We are running a mixed environment network. However, all of our > authentication is performed via LDAP, we do not have an AD on our > network, nor do we have any Windows servers, all of our servers are > running RHEL. We are working on implementing a new authentication > server that is running FreeIPA, but would like to do single sign-on via > Kerberos. I have been reading posts for the better part of two weeks > and can not find instructions that work, on how to get Windows (XP - 10) > to authenticate via Kerberos. Here is a list of some of the sites that > I have looked at: > > https://support.microsoft.com/en-us/kb/837361 > https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html > https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#id2573486 > > > http://www.freeipa.org/page/Windows_authentication_against_FreeIPA > https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Microsoft_Windows.html > > (This is an older post but I was getting desperate) > http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step > > > > So here is the problem, when I attempt to set the Realm on the Windows > client I receive the following error: > > C:\Users\randym>ksetup /setrealm CHEM.BYU.EDU > Setting Dns Domain > Failed to set dns domain info: 0xc022 > Failed /SetRealm : 0xc022 > > I have tried several varieties of this command, including setting the > domain instead of the realm and always get the same result. Can someone > please put together a step by step process that includes both server > side and client side for configuring Kerberos to work with Windows and > FreeIPA. > > Thank You in advance, > > Randy > I know that people were able to do it by creating local accounts that match IPA user accounts. AFAIK this is the only way how things can be accomplished with direct integration of Windows systems into IPA. There is work going on to support Samba for Windows systems and IPA for Linux and have trusts between them but this work is not complete on both sides. IPA needs to grow Global Catalog capability and Samba needs to complete port to MIT Kerberos. There are several things that are still missing there to be able to switch from Heimdal implementation. Also if something is not working with Windows setup you found on the freeIPA site please address your question to freeipa-users list. Also archives of that list might help too. -- Thank you, Dmitri Pal Engineering Director, Identity Management and Platform Security Red Hat, Inc. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos, Windows and FreeIPA
Hi, I think this may be working. When I was trying to make Microsoft's AD to authenticate to a Kerberos server and not the AD controlleurs we managed to get a stand alone windows to authenticate to a RHEL MIT KDC. I'm not at work atm so I can't check this on our wiki, but theses may be able to help you : http://serverfault.com/questions/129854/authenticating-windows-7-against-mit-kerberos-5 https://msdn.microsoft.com/en-us/library/bb742433.aspx Cordialement, Jean-Christophe Gay - Mail original - > De: "Russ Allbery" > À: "Randolph Morgan" > Cc: kerberos@mit.edu > Envoyé: Vendredi 23 Octobre 2015 22:17:36 > Objet: Re: Kerberos, Windows and FreeIPA > > Randolph Morgan writes: > > > We are running a mixed environment network. However, all of our > > authentication is performed via LDAP, we do not have an AD on our > > network, nor do we have any Windows servers, all of our servers are > > running RHEL. We are working on implementing a new authentication > > server that is running FreeIPA, but would like to do single sign-on via > > Kerberos. I have been reading posts for the better part of two weeks > > and can not find instructions that work, on how to get Windows (XP - 10) > > to authenticate via Kerberos. > > There used to be various workarounds that would let you do this, but when > we asked Microsoft about it, they said it was officially unsupported and > very likely to break. I think subsequent releases of Windows may have > broken it. > > I believe the only supported way to get a Windows system to use Kerberos > for its integrated login is to join the host to a domain (whether AD or > Samba). > > You can, of course, run Kerberos software on unjoined Windows hosts, get > tickets, and authenticate to Kerberos services without any trouble. The > problems arise when you want the core OS stuff to use Kerberos directly, > since I believe all of that is effectively gated on being domain-joined. > > -- > Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos, Windows and FreeIPA
Randolph Morgan writes: > We are running a mixed environment network. However, all of our > authentication is performed via LDAP, we do not have an AD on our > network, nor do we have any Windows servers, all of our servers are > running RHEL. We are working on implementing a new authentication > server that is running FreeIPA, but would like to do single sign-on via > Kerberos. I have been reading posts for the better part of two weeks > and can not find instructions that work, on how to get Windows (XP - 10) > to authenticate via Kerberos. There used to be various workarounds that would let you do this, but when we asked Microsoft about it, they said it was officially unsupported and very likely to break. I think subsequent releases of Windows may have broken it. I believe the only supported way to get a Windows system to use Kerberos for its integrated login is to join the host to a domain (whether AD or Samba). You can, of course, run Kerberos software on unjoined Windows hosts, get tickets, and authenticate to Kerberos services without any trouble. The problems arise when you want the core OS stuff to use Kerberos directly, since I believe all of that is effectively gated on being domain-joined. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Kerberos, Windows and FreeIPA
We are running a mixed environment network. However, all of our authentication is performed via LDAP, we do not have an AD on our network, nor do we have any Windows servers, all of our servers are running RHEL. We are working on implementing a new authentication server that is running FreeIPA, but would like to do single sign-on via Kerberos. I have been reading posts for the better part of two weeks and can not find instructions that work, on how to get Windows (XP - 10) to authenticate via Kerberos. Here is a list of some of the sites that I have looked at: https://support.microsoft.com/en-us/kb/837361 https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#id2573486 http://www.freeipa.org/page/Windows_authentication_against_FreeIPA https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Microsoft_Windows.html (This is an older post but I was getting desperate) http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step So here is the problem, when I attempt to set the Realm on the Windows client I receive the following error: C:\Users\randym>ksetup /setrealm CHEM.BYU.EDU Setting Dns Domain Failed to set dns domain info: 0xc022 Failed /SetRealm : 0xc022 I have tried several varieties of this command, including setting the domain instead of the realm and always get the same result. Can someone please put together a step by step process that includes both server side and client side for configuring Kerberos to work with Windows and FreeIPA. Thank You in advance, Randy -- Randy Morgan CSR Department of Chemistry and Biochemistry Brigham Young University 801-422-4100 Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Working with Microsoft Premier Support RE MIT Kerberos for Windows 4.0.1
helpd...@mit.edu is not the correct support forum for this issue. On Thu, 15 Oct 2015, Binder, Dale wrote: > > Tickets are stored in the location specified > by environment variable Yes, the software is doing what you tell it to do. The "MSLSA:" cache type corresponds to the LSA integration; KfW will only put tickets in the LSA when told to do so, such as by setting KRB5CCNAME to MSLSA:. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Working with Microsoft Premier Support RE MIT Kerberos for Windows 4.0.1
Please direct me to the resources that can answer the following:
* We have an open case with MS Premier Support and Kerberos for Windows
4.0.1 states "Integration with the Windows LSA credentials cache"
* We are using .NET webclient and can't seem to get the client to use the
tickets in the cache. Tickets are stored in the location specified by
environment variable
* See support case below
From: Frank Kim [mailto:frank@microsoft.com]
Sent: Thursday, October 15, 2015 1:59 AM
To: Binder, Dale
Cc: MSSolve Case Email; Shmain, Jeffrey
Subject: RE: Kerberos issues -> RE: [REG:115100513230017] Clarify the account
infrastructure.
Hi Dale,
In regards to the code below, the .NET code will not know anything about the
location of the MIT tickets at:
C:\Users\nbkvw7l\KerberosCacheFile\krb5cache
Kerberos tickets in Windows are stored in LSASS.exe. Internally, .NET uses
the SSPI APIs to implement Kerberos. You pass the user's credentials to SSPI
by calling AcquireCredentialsHandle(). AcquireCredentialsHandle() obtains this
in LSASS.exe as well. Internally, SSPI is implemented using the LSA APIs which
are used to interface with LSASS.exe.
The reason I have suggested using the MIT GSS APIs is because they would be
aware of the krb5cache. I am going to assume that Java uses the MIT GSS APIs
which is why things work for you.
I've read some of the docs on MIT Kerberos which indicate they store their
credentials in LSA's cache for 4.0.0. Here is the link I referenced.
http://web.mit.edu/kerberos/kfw-4.0/kfw-4.0.html
They mention the following, "Integration with the Windows LSA credentials
cache."
They don't elaborate on what this means so you would need somebody familiar
with this project to address the true meaning of this. If the following call:
GetTGT()
If this associated the MIT ticket with the current user.
The only option I could see is the following:
credentialCache.Add(new Uri("http://lpnoe0vupotd1i.bankofamerica.com:20550/";),
"Kerberos", CredentialCache.DefaultNetworkCredentials);
I'm not sure if you have tried this.
The other code below will not work just for the fact that .NET doesn't know
anything about MIT Kerberos and it's tickets. It only know about Kerberos
Tickets created by Windows and stored in LSASS. This is why you have to use
the specific GSS APIs provided by MIT.
Finally about 20 years ago, Microsoft did create a GSS API whose interface was
compatible with GSS APIs from MIT. What this meant was that you could take an
application written on Linux and rebuild it on Windows to run in the POSIX
subsystem. This is what they meant by GSS API compatibility. The interface
was compatible so a Linux developer did not have to rewrite their code to use
SSPI. (Internally, the GSS API offered by Microsoft was just a wrapper around
SSPI).
Thanks
Frank Kim (frank@microsoft.com<mailto:frank@microsoft.com>)
Sr. Escalation Engineer
Developer Tools - Windows SDK
+1 (425) 538 0692
Typical Hours - 8:30 - 17:30
(UTC-08:00) Pacific Standard Time (US & Canada)
Meeting and exceeding your expectations are my top priorities. We are
interested in any feedback you might have about the service you received on
this incident. Please let my manager, John Hornick, know what you think of the
level of service provided; email
john.horn...@microsoft.com<mailto:john.horn...@microsoft.com>, or even call
425-538-0721
Dale Binder
Develop and Manage
Cyber Security Technology
Global Information Security
Bank of America
40 N Main Street
Dayton, OH 45423
937.938.1138 (work)
937.438.3507 (cell)
[cid:image001.jpg@01CC42B3.9D534100]
--
This message, and any attachments, is for the intended recipient(s) only, may
contain information that is privileged, confidential and/or proprietary and
subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
recipient, please delete this message.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
