KRB_AP_ERR_MODIFIED w/ msDS-SupportedEncryptionTypes AES128 but not w/ AES256
ties=0x028f3bbf cbMaxToken=48000
NTLM: fCapabilities=0x02882b37 cbMaxToken=2888
TSSSP: fCapabilities=0x00810230 cbMaxToken=13000
pku2u: fCapabilities=0x00a3 cbMaxToken=12000
WDigest: fCapabilities=0x00800304 cbMaxToken=4096
Schannel: fCapabilities=0x004107b3 cbMaxToken=24576
Microsoft Unified Security Protocol Provider: fCapabilities=0x004107b3
cbMaxToken=24576
AcquireCredentialsHandle(SECPKG_CRED_INBOUND) success
QueryCredentialsAttributes success:
acctname: TsspiCompAes128$@GEMA.CORP
expires: Forever
inSecBuffer[0]: SECBUFFER_TOKEN: 0x0648 1608
fContextReq:
ASC_REQ_CONNECTION
ASC_REQ_EXTENDED_ERROR
ASC_REQ_INTEGRITY
ASC_REQ_MUTUAL_AUTH
ASC_REQ_REPLAY_DETECT
ASC_REQ_SEQUENCE_DETECT
AcceptSecurityContext: SEC_I_CONTINUE_NEEDED
fContextAttr:
ASC_RET_EXTENDED_ERROR
outSecBuffer: SECBUFFER_TOKEN: 0x0068 104
0: 60 66 06 09 2a 86 48 86 f7 12 01 02 02 03 00 7e |`f..*.H~|
00010: 57 30 55 a0 03 02 01 05 a1 03 02 01 1e a4 11 18 |W0U.|
00020: 0f 32 30 32 34 30 35 31 37 30 31 32 31 30 35 5a |.20240517012105Z|
00030: a5 05 02 03 05 46 24 a6 03 02 01 29 a9 0b 1b 09 |.F$)|
00040: 4d 45 47 41 2e 43 4f 52 50 aa 1d 30 1b a0 03 02 |GEMA.CORP..0|
00050: 01 01 a1 14 30 12 1b 10 54 73 73 70 69 43 6f 6d |0...TsspiCom|
00060: 70 41 65 73 31 32 38 24 |pAes128$|
The error buried in this KRB_ERROR is 0x29 KRB_AP_ERR_MODIFIED.
At 0x37 is tagnum a6 which is error_code, len 03, tag 02 is integer, len
01, value 0x29 is KRB_AP_ERR_MODIFIED.
KDC is plain Windows Server 2016.
Server prog is running on plain Windows Server 2016 domain member.
Client prog is running on same server under same session / user (hmmm...).
Packet captures look normal.
The failed case client gets an AES256 TGT and then an AES128 ticket as
expected.
[1] There is an AS-{REQ,REP} for the acceptor account which is slightly
unexpected (and fails if I sabotage the password so the password is
correct).
So does anyone know why using AES128 results in KRB_AP_ERR_MODIFIED?
Mike
--
Michael B Allen
Java AD DS Integration
https://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kinit without dns
On Wed, Jan 24, 2024 at 4:27 PM Sam Hartman wrote: > > >>>>> "Michael" == Michael B Allen writes: > > Michael> Hi Ken, > > Michael> Indeed. Unfortunately my stock packages on CentOS 9 Stream > Michael> are 1.21 but the KRB5_TRACE feature was introduced in 1.9. > > Last time I checked, 1.21 > 1.9. Good point and, after some fiddling, it does indeed work and would have revealed the issue: $ KRB5_TRACE=trace.txt kinit -k -t java31.keytab 'java31$@GOGO.LOCO' kinit: Pre-authentication failed: Invalid argument while getting initial credentials $ cat trace.txt 850878: Matching java31$@GOGO.LOCO in collection with result: 0/Success 850879: Getting initial credentials for java31$@GOGO.LOCO 850880: Found entries for java31$@GOGO.LOCO in keytab: aes128-cts 850882: Sending unauthenticated request 850883: Sending request (189 bytes) to GOGO.LOCO 850884: Resolving hostname dc1.gogo.loco 850885: Sending initial UDP request to dgram 10.11.12.22:88 850886: Received answer (185 bytes) from dgram 10.11.12.22:88 850887: Response was from primary KDC 850888: Received error from KDC: -1765328359/Additional pre-authentication required 850891: Preauthenticating using KDC method data 850892: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2) 850893: Selected etype info: etype aes256-cts, salt "GOGO.LOCOhostjava31.gogo.loco", params "" 850894: PKINIT client has no configured identity; giving up 850895: PKINIT client has no configured identity; giving up 850896: Preauth module pkinit (16) (real) returned: 22/Invalid argument 850897: Retrieving java31$@GOGO.LOCO from FILE:java31.keytab (vno 0, enctype aes256-cts) with result: -1765328203/No key table entry found for java31$@GOGO.LOCO 850898: Preauth module encrypted_timestamp (2) (real) returned: -1765328203/No key table entry found for java31$@GOGO.LOCO Second to last line is pretty clear. Kinit was looking for an aes256-cts key but the keytab only had an aes128-cts entry. Mike -- Michael B Allen Java AD DS Integration https://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kinit without dns
On Wed, Jan 24, 2024 at 3:34 PM Ken Hornstein wrote: > > You MIGHT be better served by turning on Kerberos tracing to see what the > library is doing. Prefixing that kinit with: > > env KRB5_TRACE=/dev/stdout > > would be useful. Hi Ken, Indeed. Unfortunately my stock packages on CentOS 9 Stream are 1.21 but the KRB5_TRACE feature was introduced in 1.9. At any rate, of course I figured out the problem right after posting this ... Even though the following AD account attribute was set to: msDS-SupportedEncryptionTypes: 0x8 (AES128_CTS_HMAC_SHA1_96) apparently this is not applicable to getting a TGT. I noticed the AP-REQ KRB5KDC_ERR_PREAUTH_REQUIRED PA-DATA listed AES256 as the etype. My keytab only had an AES128 key. Changing the key to AES256 fixed the issue and kinit now runs successfully (without modifying DNS since dc1.gogo.loco is listed in router DNS proxy local tables). ^^^TLDR So I guess the "Invalid argument" was that there was no key matching the desired etype. It probably didn't help that there was obviously an AES256 key on the account and it's only because I'm screwing around with that msDS-SupportedEncryptionTypes attr trying to pin AES128 that I'm dancing outside the lines of sanity at this point. Really glad to see KRB5_TRACE was added. Thanks for your support. Mike -- Michael B Allen Java AD DS Integration https://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
kinit without dns
Hello,
I use linux almost exclusively for everything.
DNS points to my Internet router.
However, I also have VMs running AD and various Windows instances just
for testing my software.
All of these test hosts use AD for DNS which forwards to said Internet router.
If I use the following krb5.conf with MIT krb5 packages on CentOS:
[libdefaults]
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
[realms]
GOGO.LOCO = {
kdc = dc1.gogo.loco
}
where dc1.gogo.loco is AD, trying to run kinit fails:
$ kinit -k -t java31.keytab 'java31$@GOGO.LOCO'
kinit: Pre-authentication failed: Invalid argument while getting
initial credentials
Looking at the network shows:
ProtocolLength Info
DNS 80 Standard query 0xd8af A dc1.gogo.loco
DNS 96 Standard query response 0xd8af A dc1.gogo.loco A 10.15.15.22
KRB5221 AS-REQ
KRB5234 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
DNS 79 Standard query 0x314d URI _kerberos.GOGO.LOCO
DNS 154 Standard query response 0x314d No such name URI
_kerberos.GOGO.LOCO SOA a.root-servers.net
DNS 91 Standard query 0xfc89 SRV _kerberos-master._udp.GOGO.LOCO
DNS 166 Standard query response 0xfc89 No such name SRV
_kerberos-master._udp.GOGO.LOCO SOA a.root-servers.net
DNS 91 Standard query 0xe601 SRV _kerberos-master._tcp.GOGO.LOCO
DNS 166 Standard query response 0xe601 No such name SRV
_kerberos-master._tcp.GOGO.LOCO SOA a.root-servers.net
DNS 79 Standard query 0x37d8 URI _kerberos.GOGO.LOCO
DNS 154 Standard query response 0x37d8 No such name URI
_kerberos.GOGO.LOCO SOA a.root-servers.net
DNS 91 Standard query 0x54e2 SRV _kerberos-master._udp.GOGO.LOCO
DNS 166 Standard query response 0x54e2 No such name SRV
_kerberos-master._udp.GOGO.LOCO SOA a.root-servers.net
DNS 91 Standard query 0xc1d3 SRV _kerberos-master._tcp.GOGO.LOCO
DNS 166 Standard query response 0xc1d3 No such name SRV
_kerberos-master._tcp.GOGO.LOCO SOA a.root-servers.net
As you can see, kinit successfully communicates with the KDC but then
fails over to querying DNS to find one.
Is there any way to get kinit to work without DNS?
Temporarily hacking my prod machines to use DNS for test machines is not ideal.
Ideas?
Mike
--
Michael B Allen
Java AD DS Integration
https://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?
On Thu, Aug 25, 2016 at 10:09 AM, Simo Sorce wrote: > On Wed, 2016-08-24 at 22:05 -0400, Michael B Allen wrote: >> But, again, the point is that the client would not be "joined" to a >> domain, it would not be required to have network access to a KDC, time >> on the client would not matter, the user would not necessarily have to >> run the client application in the context of the principal (meaning >> they would not have to "login" as a specific user first), the client >> would not have to do fancy SRV queries to find the right KDC and the >> client would not submit huge tickets with every single request. > > It seem most of this is thought in the context of an Active > Directory-like setup. > > In the general kerberos case you do not have to be joined to a domain or > to login as a specific user to your local machine to perform an AS > request and get a TGT. > > You do have to locate a KDC to do it though, but with IAKERB you can > defer that to the server (at least if your user and the server have > identities in the same REALM, might get complicated, but still possible, > if not). > > If supported directly in the browser you could also have multiple > different identities, all you need is for the client to keep track of > which identity to use with each server, so it can select the right > credentials/REALM to construct the AS request. > > Finally, there is no requirement to send huge tickets with each request, > because we are talking about TLS this means you maintain an HTTP 1.1 or > HTTP/2 connection for multiple requests, this is something you always > want to do when using HTTPS and if this authentication is integrated > with TLS that's what you'd do to avoid expensive secure channel > establishment exchanges anyway. So the TLS layer would always keep track > of who the user is on the other side and provide that information to the > server. That's all true. Your response was very informative and it has changed my understanding of this topic. But not completely ... Clients should not be required to have access to KDCs directly. Ideally KDCs should be on a separate network. Then make a hole for just the HTTPS server. Being able to put something "behind" a server and, more generally, partition networks by function is more secure. Also, another thing is ticket security. Kerberos in it's current form is efficient in that tickets are cached on the client but that creates the potential for those tickets to be used in unintended ways. What happened to the principle of least privilege? If you take Kerberos and flip it inside-out (or outside-in rather) and push work into the server and only give the client the bare minimum necessary to create the TLS session, use the service securely and without fully re-authenticating frequently, that would be more secure. > In cases where TLS connections are terminated early (by some sort of > load balancer for example) and you want to "tunnel the user's identity" > you can use additionally other techniques: > > * the server provides a secure cookie (a bearer token of some sort) that > is provided at authentication time, but it is kind of useless given the > above. > * exchange a session key and provide a mush smaller proof of possession > than sending the whole ticket, again kind of pointless in the case you > base your TLS authentication on the user's credentials. How could authentication be based on anything other than the user's credentials? Just to be clear about terminology, by "authentication" do you mean starting from scratch or is using a ticket which is a product of authentication that can be reused also considered "authentication"? My scheme would be no different from Kerberos in this respect. You do full authentication and the client gets a 10 hour ticket for just the particular service. It never sees a TGT. The server would handle all of that (and maybe the server never sees a TGT either). > These could be backed in browser through a standard or implemented > entirely as a server controlled mechanism via normal cookies and/or > javascript code running on the client. I am very much opposed to using cookies or JavaScript for security purposes. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?
On Wed, Aug 24, 2016 at 7:09 PM, Rick van Rein wrote: > Hey, > >>> To be clear, the whole point of what I'm proposing is that the client >>> would have ZERO dependencies. Being able to do proper auth and then >>> get a TLS session that uses the crypto context established during auth >>> instead of traditional certificate would be a big deal. > > The general idea of IAKERB is that client-KDC traffic can travel over an > unprotected link, which might involve the server. It is still important > however, to have the long-term secret (the "password") established between > client and KDC to base the trust on. Yes, the password would be required to get a service ticket. But it would get it through the server and once it has a ticket it can skip using the password for some time. More specifically, the client would open a TCP connection to the IP of the server, messages would be exchanged in a secure fashion using the password "to base the trust on", the resulting crypto context would be used instead of a traditional certificate for the TLS session and finally the client gets a service ticket that it can use to skip password authentication for 10 hours. But, again, the point is that the client would not be "joined" to a domain, it would not be required to have network access to a KDC, time on the client would not matter, the user would not necessarily have to run the client application in the context of the principal (meaning they would not have to "login" as a specific user first), the client would not have to do fancy SRV queries to find the right KDC and the client would not submit huge tickets with every single request. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?
On Wed, Aug 24, 2016 at 3:12 PM, Simo Sorce wrote: > On Wed, 2016-08-24 at 12:35 -0400, Michael B Allen wrote: >> On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein wrote: >> > Hey Mike, >> > >> >> But it would be even better if the client could (or had the option to) >> >> do authentication with the service directly and thus eliminate the >> >> numerous dependencies for clients (DNS, KDC access, stale tickets, >> >> time sync...). >> > >> > I doubt you could use Kerberos without these components involved. >> > You might forego DNS if you configured your client (which is certainly >> > not everyone's favourite solution). You need the KDC to obtain a >> > short-lasting credential, which is pretty much a cornerstone of >> > Kerberos security. The stale tickets and time sync come with that. >> >> I'm proposing clients use the server as a surrogate for the KDC. So >> the server would get a TGT on behalf of the client as well as a >> service ticket (for itself) and return it to the client. The client >> would then use that service ticket as normal. I understand that this >> would all warrant new commands and logic. > > The IAKERB mechanism was built for this scenario, but it seem like it > didn't really pick up, it worked by tunneling AS requests/replies, so it > is not the server that gets your TGT, which would be quite bad in the > general case. Ah, yes, I thought there was something like this. I suspect I am just recalling IAKERB but twisted into my own fantasy. To be clear, the whole point of what I'm proposing is that the client would have ZERO dependencies. Being able to do proper auth and then get a TLS session that uses the crypto context established during auth instead of traditional certificate would be a big deal. I don't see why giving the server access to the TGT would be any different from delegation. It could be "constrained" to just the HTTP server(s), Sharepoint, or whatever stuff requires impersonation. Mike Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?
On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein wrote: > Hey Mike, > >> But it would be even better if the client could (or had the option to) >> do authentication with the service directly and thus eliminate the >> numerous dependencies for clients (DNS, KDC access, stale tickets, >> time sync...). > > I doubt you could use Kerberos without these components involved. > You might forego DNS if you configured your client (which is certainly > not everyone's favourite solution). You need the KDC to obtain a > short-lasting credential, which is pretty much a cornerstone of > Kerberos security. The stale tickets and time sync come with that. I'm proposing clients use the server as a surrogate for the KDC. So the server would get a TGT on behalf of the client as well as a service ticket (for itself) and return it to the client. The client would then use that service ticket as normal. I understand that this would all warrant new commands and logic. Yes, this is all tangential to what you're doing. >> I'm not sure if that is possible with HTTP being >> stateless, but if is, it could be the basis for proper Internet >> website security as well. > > It sounds to me like you are asking about preshared keys, which > are accepted to be far less secure than the Kerberos road. Unfortunately I don't know all the nomenclature so I'll duck this one. Mike Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?
On Tue, Aug 23, 2016 at 10:24 AM, Rick van Rein wrote: > HTTP/Negotiate is indeed so sad that we've been working on an > alternative, that is to integrate Kerberos + Diffie-Hellman into TLS. > Then, once you get TLS going for your HTTPS, you would have established > mutual trust and perfect forward secrecy. Hi Rick, Using the Kerberos ticket as the certificate on which to build TLS without using a CA and all of the work that goes with it seems much cleaner. I'm glad to see people working on this. But it would be even better if the client could (or had the option to) do authentication with the service directly and thus eliminate the numerous dependencies for clients (DNS, KDC access, stale tickets, time sync...). I'm not sure if that is possible with HTTP being stateless, but if is, it could be the basis for proper Internet website security as well. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Beginner Kerberos question - problem with spnego authentication with webserver
On Wed, Jun 22, 2016 at 6:41 PM, JSoet wrote:
> sure where to look next to solve it. When running the flask webserver I get
> this error when it tries to do the authGSSServerInit call:
> /GSSError: (('Unspecified GSS failure. Minor code may provide more
> information', 851968), ('', 14))/
> /[root@TestCentOSGui testFlask]# klist -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
>
> --
>3 HTTP/TestCentOSGui.Test.local@TEST.LOCAL/
Hi Jordan,
That's a pretty wild principal name. I don't think the caps should
cause a problem but it is vitally important that you use the fully
principal name in the URL like:
http://TestCentOSGui.Test.local/whatever
or this *should* work equally well:
http://testcentosgui.test.local/whatever
But if you did just http://testcentosgui/whatever it would not work
unless the client does the right canonicalization.
Also, when you're setting up a new account, it is not uncommon to have
a stale ticket with the wrong knvo (principal version number). In this
case, you'll want to purge tickets on the client and try again. I
always liked kerbtray.exe for this but MS has been updating these
utilities so it might be difficult to locate.
Kerberos is pretty sensitive so the list of things to check is:
1) clients must be joined to the domain
2) clients must have direct access to a suitable domain controller
3) time on all 3 hosts (client, server and DC) must be synchronized
4) the user has to be actually logged into their workstation as the domain user
5) the numerous DNS records have to be exactly correct
6) services have to have good keys with principal names that make said
DNS records
7) Kerberos tickets cannot be "stale" (use kerbtray.exe to purge on clients)
But in your case it sounds like the client is initiating auth which
means it's getting a ticket so it's more likely to be 3, 5, 6 or 7.
This all assumes that this "flask" thing knows about SPNEGO (would be
useless without it).
Later,
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos Authentication question(s)
following C-like pseudocode:
get_header(ctx, req, 'Client-ID', &client_id);
if (lookup_outbound_destination_by_client_id(ctx, client_id,
&destination) == 0) {
if (is_outbound_destination_fast(ctx, destination) == FALSE) {
remove_outbound_destination_by_client_id(ctx, client_id);
} else {
set_outbound_destination(ctx, req, destination);
}
} else {
set_outbound_destination_in_the_usual_way(ctx, req);
}
So this is supposed to implement "server stickyness".
Then I would modify all of the browsers in the world to generate a
Clinet-ID header if they need stickyness for something like a
multi-request authentication.
Note that the stickyness is not a hard binding. A different
destination can be selected at any time. The client would just have to
rebuild whatever state is associated with the Client-ID. It just has
to be sticky enough for the client to get a reasonable amount of
stateful work done most of the time.
The Client-ID value would just be a big random number like
4043eeb322518921132308829a0e98af that would be re-generated once in a
while.
This could be the toe-hold necessary to do something like a proper
stand-alone authentication over HTTP.
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos Authentication question(s)
e is even worse, in that it ties things to the underlying > TCP/TLS connection, which is a clear violation of the spec. There are > mostly-reasonable ways to do HTTP authentication with strong crypto > (imagine an RPC-like system which gets a token that is used to > authenticate subsequent requests, with explicit parameters in the RPC to > preserve server state across iterations in the authentication loop), but > this one is not it. Actually last I checked Kerberos over HTTP does not authenticate the TCP connection. The Kerberos ticket is actually re-submitted with every single request. But NTLM does authenticate the TCP connection which makes it a violation of the HTTP spec. It's not clear to me why an authenticated TLS connection is bad in some way. Assuming the certs are proper and the chain of authority is validated by both ends and such, I would think that would be pretty secure. But re-submitting the Kerberos ticket with each request and / or using TLS just to make the auth step stateful is pretty inefficient (especially if there's a big PAC in the Kerberos ticket). However, I don't really blame HTTP-Negotiate or HTTP-NTLM for violating the HTTP spec because the HTTP spec provides NO WAY to do a complete stand-alone authentication. Authentication is inherently stateful because there is always some kind of "challenge" or "nonce" that one or both sides must factor into a hash that the other end needs to compute separately to prove that the other end knows The Secret. So if a client starts authentication with one HTTP server and a "nonce" is computed and saved in some state on the server but the next request gets routed to a different server, that server will have no knowledge of the nonce and thus authentication is not possible. This is why Digest Authentication is vulnerable to replay attacks because it carries the "nonce" with the request. Because subsequent requests could go to a different server, the server cannot save the nonce to verify it's not being replayed. So a Digest server implementation would have to just trust the nonce to be truely stateless. Note that Kerberos over HTTP is not a complete stand-alone authentication. The authentication already happened when the client got a TGT from a third party service. The client is just passing what is effectively a temporary key that must be validated by said third party. I'm not sure what you mean by using RPCs but bear in mind that any kind of third party service could NOT be based on HTTP (because that would just be pushing the poop around without actually getting rid of it). And a non-HTTP based third party authentication service probably would not play well on the Internet. So HTTP sites are still processing plaintext passwords on the server which is of course ridiculously insecure ... I haven't really thought too much about this but I have to wonder if it would be better to make HTTP optionally / partially stateful where a client could generate a "Client-ID" every once in a while which would just be a long random number and then require HTTP proxies and load balanacers and such to maintain an index of these IDs and then *try* to route requests to the same downstream server. I think they already pretty much have to do this for TLS and proxies worth more than their weight in bytes probably already do this for session IDs to implement session stickyness. But with the Client-ID method it would not have to be tied to a TCP connection and with one new header we might knock out cookies and session ids and other such things which of course are just weak methods that try to work-around HTTP being stateless. WRT authentication, the server would just use the Client-ID to lookup the authentication state. And if the Client-ID also included an integrity code, that would go a looong way. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos Authentication question(s)
argely compatible with the Kerberos token and more generally the GSSAPI token where GSSAPI is the RFC definition of this type of authentication which is meaningful because JGSS is the Java implementation of this and this is a run-on sentence. Meaning GSSAPI's GSS_Init_sec_context() is largely compatible with Windows' InitializeSecurityContext(). So with respect to actually coding a Java HTTP client to do Kerberos, something would ultimately need to call GSSManager.createContext with the Kerberos OID and then GSSContext.initSecContext and then the result of looping over that consumes and emits a "token" (which *should* then be wrapped in the SPNEGO business) and Base64 encoded / decoded. Maybe the "Hadoop" library is doing that for you. I'm not familiar with it. Personally I would be very skeptical of libraries that do this type of stuff. HTTP authentication is actually a lot harder than it looks because HTTP is stateless and so technically trying to do authentication (which is inherently stateful) over a stateless protocol is something of an oxymoron. So test your code carefully using all of the possible environmental parameters like different servers or whatever. > 2) What fields of that auth token have to be set to what values? > 3) What is the encryption algorithm used to encrypt the auth token > against the keytab key? > 4) What is the best keytab key to use? > 5) What is the mechanism for byte-serializing the auth token, once > encrypted? As described above, fortunately you probably don't have to worry about the actual content of the token as it is largely handled by GSSAPI / JGSS. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Java code performing Kerberos password AuthN
On Fri, Jun 27, 2014 at 10:06 AM, Jorj Bauer wrote: >> Note that you can dodge the jaas.conf by installaing your own >> Configuration like: > > Thanks for the comment. I know about this, generally speaking - it's what I > was alluding to in the README: > >> (There is probably >> a more complex Configuration object setup that could be performed here >> to populate the settings programmatically; I chose to not go down that >> road due to complexity of the code that might be required.) > > Specifically - and maybe you can help here - I have two concerns about that > approach. > > First: there are two different configurations in jaas.conf (one for client > and one for server behavior). I presume it's possible to construct a > programmatic configuration that adds both, but I haven't thought about how. Hi Jorj, It's been a while since I looked at any of this. So I'm actually drawing a blank on the client vs server conf. Not sure. > Second: setting the realm and/or KDC using System.setProperty > java.security.krb5.realm and/or java.security.krb5.kdc, I wasn't able (in my > limited testing) to make it perform failover when the primary was > unreachable. Seeing that it worked fine with krb5.conf, I decided to punt, > choosing functionality over form. Ah yes, this is another gem. There are so many problems with DNS relative to Java's Kerberos I don't want to get into it. Having the realm come out of the krb5.conf isn't a complete disaster since that might actually be set properly and wouldn't be something you would want to change I would think. At least this is no different from how MIT or Heimdal handles things so I can't trash Java too much for doing it. Kerberos and DNS are so tightly coupled that dumping off DNS to the system resolver just doesn't cut it. I think the only way to provide proper DNS behavior for Java's Kerberos would be to actually completely override it with a property like sun.net.spi.nameservice.provider. Again, of course the property is global and static so it will effect everything in the same ClassLoader so your DNS implementation better be pretty solid. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Java code performing Kerberos password AuthN
On Thu, Jun 26, 2014 at 6:23 PM, Jorj Bauer wrote:
> Maybe someone will show me a better way to do it in Java, for that matter.
Hi Jorj,
Note that you can dodge the jaas.conf by installaing your own
Configuration like:
class Krb5Configuration extends Configuration {
final Map options = new HashMap(4);
final AppConfigurationEntry[] entries = new AppConfigurationEntry[1];
Krb5Configuration() {
super();
entries[0] = new AppConfigurationEntry(
"com.sun.security.auth.module.Krb5LoginModule",
AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
options);
}
public AppConfigurationEntry[] getAppConfigurationEntry(String name) {
return entries;
}
public void refresh() {
}
}
Then create the config and install it like:
Krb5Configuration conf = new Krb5Configuration();
conf.setOption("doNotPrompt", "true");
conf.setOption("storeKey", "true");
conf.setOption("useKeyTab", "true");
conf.setOption("debug", "true");
conf.setOption("principal", spn);
conf.setOption("keyTab", keytab);
Configuration.setConfiguration(conf);
Now you can do JGSS stuff and it should use your config. A more
sophisticated implementation might augment the existing config from
the jaas.conf to minimize chances of breaking other krb5 users in the
same ClassLoader.
Java's builtin Kerberos implementation is a mess. Even if you override
the config file like above it's still global. No config should be
global - especially in a library. Last I checked you can't get a TGT
from a KerberosKey (keytab entry) on Windows. You have to use
Krb5LoginModule and actually go through a login with a plaintext
password first because they had to go through the Windows SSPI to
access the ccache. The API is horrible as evidenced by the flaming
hula hoops you had to go through to do anything remotely
sophisticated.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Is Windows server 2008+KDC not interoperable with Java, Solaris and UNIX or MIT kerberos?
On Thu, Jul 28, 2011 at 6:50 PM, Sabharanjak, Ravi wrote: > Even omitting des from the default enctypes gets the same result - > KRB5KDC_ERR_ETYPE_NOSUPP. So as long as I have aes specified, I get "no > support" in the response. > > I can understand the Java issue, but this behavior is with the latest Java > off the web and also with the MIT release and the UNIX and Solaris releases. > > I can see the exchange as follows (on solaris): > - AS-REQ from client, specifying Encryption Types: aes256-cts-hmac-sha1-96 > aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc > - Error: KRB5KDC_ERR_PREAUTH_REQUIRED from the kdc. This does have aes > specified in the PA-ENCTYPE-INFO2 in the e-data field as follow: > Value: 3064301da003020112a1161b144e412e424c4b494e542e43... > aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-md5 des-cbc-crc > - Client repeats AS-REQ, includes Encryption Types: aes256-cts-hmac-sha1-96 > aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc > - Server responds with KRB5KDC_ERR_ETYPE_NOSUPP I don't understand. The above shows DES enctypes in the list. I assume this is without using default_tkt_enctypes / default_tgs_enctypes set? What enctype did Java use to encrypt the padata in the AS-REQ? Mike > -Original Message- > From: Michael B Allen [mailto:iop...@gmail.com] > Sent: Thursday, July 28, 2011 3:22 PM > To: Sabharanjak, Ravi > Cc: kerberos@mit.edu > Subject: Re: Is Windows server 2008+KDC not interoperable with Java, Solaris > and UNIX or MIT kerberos? > > On Thu, Jul 28, 2011 at 4:49 PM, Sabharanjak, Ravi > wrote: >> The syntax is actually - >> default_tkt_enctypes = rc4-hmac >> default_tgs_enctypes = rc4-hmac >> >> That works, However that locks my clients down to rc4-hmac forever and I >> don't want to do that. I would like them to move up to aes automatically >> when the KDC supports it and negotiate (not hard-code) rc4-hmac till that >> happens. > > And if you specify multiple mechanism names separated by spaces like: > > default_tkt_enctypes = aes128-cts rc4-hmac > default_tgs_enctypes = aes128-cts rc4-hmac > > Does that still "lock" clients into a particular mechanism? > >> It can't be the des in the request that would turn the kdc off - it is >> supposed to pick an acceptable mechanism from the list proposed, and it >> should negotiate rc4-hmac according to me. > > Yes, the KDC is supposed to pick an appropriate mechanism but if your > observations are accurate, then apparently that is not the case. You said a > capture showed Java offering RC4 and AES but you still got > KRB5KDC_ERR_ETYPE_NOSUPP anyway. So maybe if you explicitly specify two mechs > it will negotiate properly. > > Otherwise it is possible that this could be traced back to an obscure > incompatibility in the builtin Java Kerberos implementation. As I said > before, it has had a troubled history. > > Actually now that I think about it, an XP SP2 client will offer to do DES. So > I don't see how a Windows KDC could proactively reject DES and maintain > backward compatibility. Maybe your security policy has been tweaked to reject > DES in this way. > > Just hypothesizing. > > Mike > > -- > Michael B Allen > Java Active Directory Integration > http://www.ioplex.com/ > > >> -Original Message- >> From: Michael B Allen [mailto:iop...@gmail.com] >> Sent: Thursday, July 28, 2011 1:02 PM >> To: Sabharanjak, Ravi >> Cc: kerberos@mit.edu >> Subject: Re: Is Windows server 2008+KDC not interoperable with Java, Solaris >> and UNIX or MIT kerberos? >> >> On Thu, Jul 28, 2011 at 2:22 PM, Sabharanjak, Ravi >> wrote: >>> Hello all, >>> >>> I am not able to get a ticket from a server 2008 or a server 2008 R2 KDC >>> from a Java, Solaris or Linux client unless I constrain the client to use >>> RC4-HMAC for the encryption types. (Have tried this using kfw-3-2-2 on >>> Windows as well). Is server2008+ not interoperable with these Kerberos >>> implementations? >>> >>> A brief background - if the domain is not in server 2008+ functionality >>> mode (ie there are 2003 or older domain controllers in the environment), >>> server 2008+ does not enable support for AES encryption (unless the client >>> is a vista+ client that has updated the msDS-SupportedEncryptionTypes >>> attribute in its user object). Server 2008+ also does not enable support >>> for DES by default. >>> >>> In the network traces, I can see clients proposing to use DES, RC4-HM
Re: Is Windows server 2008+KDC not interoperable with Java, Solaris and UNIX or MIT kerberos?
On Thu, Jul 28, 2011 at 4:49 PM, Sabharanjak, Ravi wrote: > The syntax is actually - > default_tkt_enctypes = rc4-hmac > default_tgs_enctypes = rc4-hmac > > That works, However that locks my clients down to rc4-hmac forever and I > don't want to do that. I would like them to move up to aes automatically when > the KDC supports it and negotiate (not hard-code) rc4-hmac till that happens. And if you specify multiple mechanism names separated by spaces like: default_tkt_enctypes = aes128-cts rc4-hmac default_tgs_enctypes = aes128-cts rc4-hmac Does that still "lock" clients into a particular mechanism? > It can't be the des in the request that would turn the kdc off - it is > supposed to pick an acceptable mechanism from the list proposed, and it > should negotiate rc4-hmac according to me. Yes, the KDC is supposed to pick an appropriate mechanism but if your observations are accurate, then apparently that is not the case. You said a capture showed Java offering RC4 and AES but you still got KRB5KDC_ERR_ETYPE_NOSUPP anyway. So maybe if you explicitly specify two mechs it will negotiate properly. Otherwise it is possible that this could be traced back to an obscure incompatibility in the builtin Java Kerberos implementation. As I said before, it has had a troubled history. Actually now that I think about it, an XP SP2 client will offer to do DES. So I don't see how a Windows KDC could proactively reject DES and maintain backward compatibility. Maybe your security policy has been tweaked to reject DES in this way. Just hypothesizing. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ > -Original Message- > From: Michael B Allen [mailto:iop...@gmail.com] > Sent: Thursday, July 28, 2011 1:02 PM > To: Sabharanjak, Ravi > Cc: kerberos@mit.edu > Subject: Re: Is Windows server 2008+KDC not interoperable with Java, Solaris > and UNIX or MIT kerberos? > > On Thu, Jul 28, 2011 at 2:22 PM, Sabharanjak, Ravi > wrote: >> Hello all, >> >> I am not able to get a ticket from a server 2008 or a server 2008 R2 KDC >> from a Java, Solaris or Linux client unless I constrain the client to use >> RC4-HMAC for the encryption types. (Have tried this using kfw-3-2-2 on >> Windows as well). Is server2008+ not interoperable with these Kerberos >> implementations? >> >> A brief background - if the domain is not in server 2008+ functionality mode >> (ie there are 2003 or older domain controllers in the environment), server >> 2008+ does not enable support for AES encryption (unless the client is a >> vista+ client that has updated the msDS-SupportedEncryptionTypes attribute >> in its user object). Server 2008+ also does not enable support for DES by >> default. >> >> In the network traces, I can see clients proposing to use DES, RC4-HMAC and >> AES for the AS-REQ if they are not configured to be limited to using >> RC4-HMAC. I am expecting the client and the KDC to settle on the use of >> RC4-HMAC, however the KDC replies with KRB5KDC_ERR_ETYPE_NOSUPP. >> >> I don't want to constrain the clients to use just RC4-HMAC, as I want them >> to switch to AES automatically when the domain functional level is upgraded >> and AES support becomes available on the DC. >> >> The Java version is the latest off Java.com. The linux and Solaris versions >> are fairly current. >> >> Wireshark traces attached. Any help you can provide or insights into why >> this is not working out would be greatly appreciated. > > Hi Ravi, > > I think you probably need to do something like: > > permitted_enctypes = aes128-cts rc4-hmac > > [But I just typed this in from memory, double check at your end what the > right parameter values are.] > > It sounds like Windows does not like clients even offering to do DES maybe. I > agree that the Windows KDC should probably just ignore DES but maybe that's > Windows' way of disabling DES at the front door as a precaution in the case > were old accounts still have DES keys laying around. Java shouldn't even be > trying DES anymore. Make sure you're not using an old Java. But I would not > be surprised if Java is still trying to do DES. The Java Kerberos > implementation is not particularly good and it has had a sorry history. > > Mike Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Is Windows server 2008+KDC not interoperable with Java, Solaris and UNIX or MIT kerberos?
On Thu, Jul 28, 2011 at 2:22 PM, Sabharanjak, Ravi wrote: > Hello all, > > I am not able to get a ticket from a server 2008 or a server 2008 R2 KDC from > a Java, Solaris or Linux client unless I constrain the client to use RC4-HMAC > for the encryption types. (Have tried this using kfw-3-2-2 on Windows as > well). Is server2008+ not interoperable with these Kerberos implementations? > > A brief background - if the domain is not in server 2008+ functionality mode > (ie there are 2003 or older domain controllers in the environment), server > 2008+ does not enable support for AES encryption (unless the client is a > vista+ client that has updated the msDS-SupportedEncryptionTypes attribute in > its user object). Server 2008+ also does not enable support for DES by > default. > > In the network traces, I can see clients proposing to use DES, RC4-HMAC and > AES for the AS-REQ if they are not configured to be limited to using > RC4-HMAC. I am expecting the client and the KDC to settle on the use of > RC4-HMAC, however the KDC replies with KRB5KDC_ERR_ETYPE_NOSUPP. > > I don't want to constrain the clients to use just RC4-HMAC, as I want them to > switch to AES automatically when the domain functional level is upgraded and > AES support becomes available on the DC. > > The Java version is the latest off Java.com. The linux and Solaris versions > are fairly current. > > Wireshark traces attached. Any help you can provide or insights into why this > is not working out would be greatly appreciated. Hi Ravi, I think you probably need to do something like: permitted_enctypes = aes128-cts rc4-hmac [But I just typed this in from memory, double check at your end what the right parameter values are.] It sounds like Windows does not like clients even offering to do DES maybe. I agree that the Windows KDC should probably just ignore DES but maybe that's Windows' way of disabling DES at the front door as a precaution in the case were old accounts still have DES keys laying around. Java shouldn't even be trying DES anymore. Make sure you're not using an old Java. But I would not be surprised if Java is still trying to do DES. The Java Kerberos implementation is not particularly good and it has had a sorry history. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Java GSS client talking to SSPI C++ Server
On Wed, Feb 23, 2011 at 6:01 PM, Ali Akhavan wrote: > Hello Kerberosians J > > > > My intention is to delegate impersonation from a Java client to a C++ > server. The Java client uses JAAS to authenticate and impersonate using > doAsPriviledged() and finally starts establishing a security context > with the server. The server is C++ and is supposed to use SSPI library > to accept this context. Is there any sample code close to my setup that > someone has ? > > > > My concern is the compatibility of the tokens generated by JAVA GSS-API > and that of SSPI. I know that at the wire-level they should be > compatible, but a working example would greatly help me. Hi Ali, Strangely there are not a lot of good JGSS examples on the web. But just google for "JGSS initSecContext" and that should get you started. The tokens are fully compatible. Java is just going to take the token supplied by AD and pass it up to the acceptor / server. It doesn't even decode it (it can't because it's encrypted with the server key). So the delegated token should even have group SIDs in it and so on. AD is actually is a pretty good KDC for non-Windows clients (although the tools provided by Microsoft for using it with non-Windows clients borderline on useless of course - e.g. ktpass). Now getting it to all work properly and see delegation work consistently is another matter. The builtin Java GSSAPI and Kerberos implementation has always been a bit of a turd. It requires a krb5.conf so it's not as stateless as libraries should be. It uses local DNS so you might not have the right SRV records (certainly not for AD Sites and Services support which can sometimes be a show-stopper) and AFAIK it won't gracefully failover to other nameservers. The Windows and non-Windows implementations are different because the Windows implementation needs to tap into the local credential cache so you should write it on the platform you're going to use it with and test it on the others when you're done. Also, I don't think Java's Kerberos library supports the "enterprise" principal name type (10) so you can't use userPrincipalName as the client principal (Windows people call this the eUPN or "explicit UPN"), you have to use samaccountn...@dns.domain.name (iUPN or "implicit UPN"). Anyway these are just the warts that come to mind at this moment. But if you pound your face into the keyboard long enough you should be able to get Java's Kerberos implementation to work. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Win 2008R2 kdc and linux client: no support for encryption type while getting initial credentials - SOLVED
On Tue, Mar 23, 2010 at 7:30 AM, John Jasen wrote: > Michael B Allen wrote: > >> Actually I would not be surprised if that "hot fix" is never made >> public. DES is being phased out. If you have any Windows accounts that >> use DES, you should update them to AES-256, AES-128 or RC4 in that >> order of preference. > > I'd have to check again, but I think linux-nfs still uses DES. Well as an NFS on Linux user (albeit without Kerberos) I hope whomever is responsible for that code has a plan to parameterize the enctype. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Win 2008R2 kdc and linux client: no support for encryption type while getting initial credentials - SOLVED
On Mon, Mar 22, 2010 at 12:01 PM, Lars Schimmer wrote: > Hi! > > Just want to note here, that problem was solved with a (not yet public) > patch from Microsoft. > http://support.microsoft.com/?kbid=978055 > > Go and ask your Microsoft Support for it. > > Looks like it only happens on x64 servers. Hi Lars, Actually I would not be surprised if that "hot fix" is never made public. DES is being phased out. If you have any Windows accounts that use DES, you should update them to AES-256, AES-128 or RC4 in that order of preference. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Kerberos Direct Service Authentication without Client / KDC Communication?
Hi All, Is there a mode of operation where a Kerberos client can directly authenticate with a service without first communicating with a KDC? Kerberos currently requires that clients are using a suitable DNS server, have access to whatever KDCs DNS is referring it to and have relatively accurate time. In many environments these requirements are too demanding. There should be a mode of operation where a client can compose a kerberos request without communicating with the KDC, DNS or time services and which can be submitted directly to a Kerberos service. This request would contain information about the client principal and target principal and would be encrypted using the client principal secret key known only to the client and the KDC. The Kerberos service accepting this ticket could compose a request containing the client's request and pass this to a KDC as a sort of AS-REQ. In return the service would receive either an error (such as indicating that the client request could not be successfully decrypted) or a service ticket with the usual fields like authorization-data and possibly a TGT that would be equivalent to a TGT that a client might normally submit through delegation. The service would then pass the service ticket down to the client to indicate that authentication was successful. The objective is to have the Kerberos service act as a proxy to the KDC so as to release the client from impractical communication and configuration requirements. The client should only need to know the shared secret. If such a thing does not already exist, I think it should. Mike Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Enquiry - Kerberos
On Sun, Jan 31, 2010 at 7:54 PM, Charles wrote: > Dear Sir/Madam, > > Can you please provide me details documentation as of how kerberos works in > Microsoft Windows. Hi Charles, Kerberos in Windows is pretty much what RFC 1510 defines: http://www.ietf.org/rfc/rfc1510.txt Note that this RFC is unusually well written and understandable for an RFC. For a more glazed over description of Kerberos in Windows, just go to msdn.microsoft.com and search on "Kerberos". Here's a link: http://msdn.microsoft.com/en-us/library/aa378747(VS.85).aspx Of course MS has a few extensions. They added a feature called constrained delegation. They come up with their own password changing / setting protocol. When acquiring a TGT MS clients use a special KRB5_NT_ENTERPRISE_PRINCIPAL (10) name type. They added a "PAC" to tickets which goes in what the RFC calls the authorization-data field which contains ... well, authorization data. So there are some MS specific things that cannot be ignored but otherwise, the core Kerberos 5 protocol implementation in Windows is the same as that of MIT or Heimdal. In fact many of these "extensions" are making their way into the other implementations either because they good (password protocol) or because Active Directory is ubiquitous. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT kinit with AD userPrincipalName with SMTP domain and not proper realm?
On Sat, Nov 21, 2009 at 5:44 AM, Luke Howard wrote: >> Meaning if I have a realm EXAMPLE.LOCAL and an SMTP domain EXAMPLE.COM >> and userPrincipalName attributes on accounts in AD use the SMTP domain >> like al...@example.com can initial credentials be acquired? >> >> If I try kinit I get: >> >> $ kinit -f al...@example.com >> kinit(v5): Cannot resolve network address for KDC in realm >> EXAMPLE.COM while getting initial credentials > > kinit -E -f al...@example.com@EXAMPLE.LOCAL > > NB: if this doesn't work in 1.7, try trunk, I think it may have been broken > in 1.7. Hi Luke, I understand now. Unfortunately, in practice, I need much more than kinit. I'm integrated with an old version of Heidmal so it seems I'll need to work on moving to a newer Heimdal and possibly work on krb5/principal.c:build_principal et al if the latest Heimdal doesn't already have it. I also want to do this with Java but given the spotted history of Java's builtin Kerberos implementation I don't expect that to be tackled easily. I kinda wish I just had a really solid ASN.1 compiler and crypto lib for the various languages. Ho-hum. Thanks, Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT kinit with AD userPrincipalName with SMTP domain and not proper realm?
Well it's all coming back to me now. It seems this has been discussed before:
http://mailman.mit.edu/pipermail/kerberos/2007-October/012373.html
The userPrincipalName is only used if the principal type is 10
(KRB5_NT_ENTERPRISE_PRINCIPAL or perhaps GSS_C_NT_ENTERPRISE_PRINCIPAL
if GSSAPI supported such a thing). AD will also canonicalize the
supplied name in the AS-REP to the samaccountn...@dnsroot.
As for the domain, I'm still a little fuzzy there as well. I would
have to take some captures to see if the Windows client tries to
lookup the domain name supplied or if it simply ignored the @domain
and sent the AS-REQ to the default authority.
Mike
On Fri, Nov 20, 2009 at 7:48 PM, Michael B Allen wrote:
> Hi,
>
> Is it possible to acquire credentials using kinit from AD using the
> userPrincipalName on an AD account if the DNS domain does not match
> the AD realm?
>
> Meaning if I have a realm EXAMPLE.LOCAL and an SMTP domain EXAMPLE.COM
> and userPrincipalName attributes on accounts in AD use the SMTP domain
> like al...@example.com can initial credentials be acquired?
>
> If I try kinit I get:
>
> $ kinit -f al...@example.com
> kinit(v5): Cannot resolve network address for KDC in realm
> EXAMPLE.COM while getting initial credentials
>
> If I then add the following to my krb5.conf:
>
> [realms]
> EXAMPLE.COM = {
> dc1.example.local
> }
>
> and try kinit again I get:
>
> $ kinit -f al...@example.com
> kinit(v5): KRB5 error code 68 while getting initial credentials
>
> and a capture shows the AS-REQ realm and service realm is EXAMPLE.COM.
> Error code 68 is KDC_ERR_WRONG_REALM.
>
> Adding .example.com = EXAMPLE.COM to [domain_realm] doesn't appear to
> have any effect.
>
> Of course using the implied principal name @ works:
>
> $ kinit -f al...@example.local
> Password for al...@example.local: ...
>
> Windows must be able to do this. How does a Windows client know that
> the SMTP domain should be substituted with a proper realm and which
> one?
>
> Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
MIT kinit with AD userPrincipalName with SMTP domain and not proper realm?
Hi,
Is it possible to acquire credentials using kinit from AD using the
userPrincipalName on an AD account if the DNS domain does not match
the AD realm?
Meaning if I have a realm EXAMPLE.LOCAL and an SMTP domain EXAMPLE.COM
and userPrincipalName attributes on accounts in AD use the SMTP domain
like al...@example.com can initial credentials be acquired?
If I try kinit I get:
$ kinit -f al...@example.com
kinit(v5): Cannot resolve network address for KDC in realm
EXAMPLE.COM while getting initial credentials
If I then add the following to my krb5.conf:
[realms]
EXAMPLE.COM = {
dc1.example.local
}
and try kinit again I get:
$ kinit -f al...@example.com
kinit(v5): KRB5 error code 68 while getting initial credentials
and a capture shows the AS-REQ realm and service realm is EXAMPLE.COM.
Error code 68 is KDC_ERR_WRONG_REALM.
Adding .example.com = EXAMPLE.COM to [domain_realm] doesn't appear to
have any effect.
Of course using the implied principal name @ works:
$ kinit -f al...@example.local
Password for al...@example.local: ...
Windows must be able to do this. How does a Windows client know that
the SMTP domain should be substituted with a proper realm and which
one?
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Getting a Windows username from an SID with Kerberos
On Thu, Oct 8, 2009 at 5:31 AM, Toby Newman wrote: > I am running Linux in a corporate windows environment. > > I need to convert user's Active Directory security identifiers (SIDs) > to usernames, for example S-1-5-21-484763869-1275210071-682003330-34567 > to mydomain\jbloggs. > > There are a few Windows tools that do this like SIDDecode and > SidToName, but they don't work under wine. > > I've been reading about Kerberos and it seems it may be > possible to achieve this. Does anyone here know how? Hi Toby, Kerberos has nothing to do with SIDs. SIDs are just the numeric id of an account in Windows. So this is off topic for this list but I'll give you some pointers: 1. Use rpcclient from the Samba package 2. Google for JCIFS, create a jcifs.smb.SID, use resolve() with suitable credentials and then toDisplayString(). Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Multiple Apache websites using Kerberos authentication (through the mod_auth_kerb module)
On Fri, Sep 11, 2009 at 8:56 AM, Caron, Christian wrote: > Hi list, > > We have been successful in having users authenticate through the > Kerberos mechanism on one website. The website has the same name and > uses the same IP as the server itself (this is the name that was used to > create the Service Principal account). > > When trying to use the same mechanism for a second website (different > name, different IP, same physical server), it doesn't work. > > Is it possible to have only one Service Principal account and "attach" > multiple websites to it and how can we achieve that? We would like to > minimize the number of accounts in AD (if possible, only one per > physical server). Yes. Unfortunately because the MS ktpass.exe utilitiy is very simple, it's not exactly easy. But first, perhaps it is better to explain how this works. Then you can actually make sense of the solution. When a browser on an AD network authenticates with a website using Kerberos, it goes something like this (this is mostly the same for a non-AD Kerberos authority but most people are using AD so I'll describe it with AD specific language): 1. Browser looks at the URL and derives a Service Principal Name (SPN). For example, if the URL is http://www.example.com/ the SPN will be HTTP/www.example@example.com. This is just simple text manipulation. 2. Browser asks AD for a "ticket" for that SPN. AD will search through all accounts for one that has a servicePrincipalName attribute that matches the supplied SPN. If one matches, it uses that account and it's corresponding password to create and return the requested ticket. 3. Browser submits the ticket to the HTTP server which decodes it (such as with mod_auth_kerb), looks at the SPN, key version number (kvno) and encryption type and tries to locate a keytab file entry that matches those three criteria exactly. If it finds one, it uses that keytab entry to decrypt the ticket and in doing so authenticate the client. In your case, the relevant part is that the servicePrincipalName attribute on AD accounts is multi-valued. So you can add any number of SPNs to an account using either setspn.exe or ADSI Edit. AD will find the account by any of those names. In fact, people frequently use both long and short names like HTTP/as1.example.com and HTTP/as1 (note that the actual servicePrincipalName attribute value does not include the @EXAMPLE.COM domain part) so that people can authenticate with the site using either http://as1/ as well as http://as1.example.com/. Personally I think using the short names is a bad idea but it seems to work and the short name does not require Intranet zone configuration on the client browser. Note that one thing to watch out for is that AD will fail to return a ticket if the SPN requested is found on more than one account (because it doesn't know which account to use). So be careful that you do not accidentally create multiple service accounts with the same SPN. Now for the bad news. As I stated, ktpass.exe is very simple. It only generates a keytab with *one* entry. Uhg! So it will simply not do the job. However, if you know the password, you can create a keytab yourself using ktutil on a *nix machine with any number of entries. To do that, first run ktpass.exe once and make a note of the output. In particular you want to note the key version number (kvno), encryption type and of course the password you entered. The encryption type might displayed as a name whereas you will need to know the numeric value for that name. Currently this is usally RC4 which I believe is 23 (I don't remember off the top of my head). Now run ktutil on *nix and create an entry for each SPN with the same password, encryption type and kvno, save the keytab and use that with mod_auth_kerb. There are also utilities that can set the password and generate a keytab with multiple SPNs in one go. Also, professional software that does Kerberos auth usually includes some capability to do all of this for you. If you're using a bare-bones solution like mod_auth_kerb, it's up to you to create a keytab. Good luck, Mike -- Michael B Allen PHP Active Directory Integration http://www.ioplex.com/plexcel.html Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: noob question on where to start with Kerberos
On Mon, Jul 27, 2009 at 6:07 PM, Bryan Boone wrote: > > Hi everyone I have a noob question for ya. > > > > I need to develop a website for a company that uses kerberos login, the web > server resides on a different server than the kerberos server. Unfortunatly > I cannot use the built in PHP functions for kerberos, so I need to write my > own C kerberos client as a PHP extension. Hi Bryan, You don't need a full-blown kerberos client. For SSO you just need an "accept_sec_context" function that consumes the base64 encoded tokens supplied by the browser and emits base64 encoded tokens to send to the browser. This function would largely call GSSAPI's gss_accept_sec_context or Windows' AcceptSecurityContext. For explicit username / password based logins you just need to call krb5_get_init_creds_password. However, it sounds like you're using Apache in which case there are already a few modules that do GSSAPI authentication. In particular there's mod_auth_kerb. You also mention PHP in which case check out http://www.ioplex.com/plexcel.html which does everything you want and a whole lot more. > Also to eliminate possible man-in-the-middle attacks, I need to have the > keytab file manually uploaded to the web server. The keytab is required to participate in any form of Kerberos authentication. By MITM I believe you're referring to validating the client supplied ticket. There's a verify-something-or-other function in the krb5 API for this. I don't recall the name of it. Someone else will probably chime in with the name of it. I don't know if mod_auth_kerb does explicit logins using krb5_get_init_creds_password. > My question is, what methods are best for accomplishing my task. Can this be > accomplished with the pam_krb5 api, the SASL for GSSAPI, or do I need to > stick with native GSSAPI? Which one would be easier for a noob? There are two methods. There is the explicit username and password based login as I mentioned which would require using krb5_get_init_creds_password or on Windows I believe you would have to do InitSecurityContext and AcceptSecurityContext in a loop (is there a short cut for this?). But there is also something called SPNEGO (which IE and MS call "Negotiate"). SPNEGO is a Single Sign-On (SSO) form of authentication which ultimately means that, with a properly configured browser, the user goes straight in without entering a password at all. On corporate intranets this is a highly desirable feature. You do not want to do anything with PAM or SASL. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos auth against AD, keytabs, and service principal names
On Mon, Jul 20, 2009 at 2:23 PM, wrote: > I've been able to use ktpass.exe on the Windows (2003R2) side to > create working keytabs for my NFSv4 environment. I'd like to have > both host/ and nfs/ service principal names for each host.fqdn in my > (DNS) domain. To this end I ran 'setspn -A ...' to create a SPN for > host/host.fqdn and nfs/host.fqdn and then I ran ktpass.exe to create a > keytab for each of host/host.fqdn and nfs/host.fqdn. Ktpass sets the password on an account and not an SPN. SPNs are linked to an account. Meaning, each time you run ktpass.exe it invalidates whatever keytab you generated with a previous invocation of ktpass.exe so that's why it doesn't work. > Then I copied the keytabs to my Linux system and tested kinit for > host/host.fqdn and nfs/host.fqdn. kinit for nfs/host.fqdn worked but > kinit for host/host.fqdn *failed*. What?! Looking at my entries in > AD, it appears that ktpass.exe sets both userprincipal name and > serviceprincipal name to *the same thing* and merely adding SPNs to > the host.fqdn entry in AD doesn't fix the problem with kinit -- if > princ/host.fqdn doesn't exist in AD as a UPN. That is to say, only > UPNs are consulted when I kinit some princ/host.fqdn? Ktpass is a very simple program and cannot be used for what you are doing. You need to generate a single keytab with multiple entries - one for each SPN. You can do this by setting the password on the service account to a known value and then using ktutil to create a keytab with multiple entries with principals for each SPN but with the same key. Note that if you have PHP running somewhere there is a product called Plexcel (one installation free for up to 25 users) that can generate keytabs with an entry for each SPN in AD. The exact function is described here: http://www.ioplex.com/api/plexcel_gen_service_keytab.html but you can also commandeer the included setup.php to do this without writing any code. After you set the password in setup.php there will be a keytab in the Plexcel tmp directory with an entry for each SPN in AD for the account. And you can create the service account and set the password entirely from Plexcel. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: second keytab for similar service (but different SPN/IP) breaks the first
On Tue, Jun 2, 2009 at 7:12 PM, Chris wrote: > So it seems that with both Active Directory's Kerberos and Open > Directory's (MIT) Kerberos I cannot have two instances of "fooservice" > kerberized on different IP addresses against distinct SPN's associated > with the same service account.. You really should create separate service accounts for each instance of the service. In theory you might be able to shoehorn it so that two instances of the service can use the same service account but the convention is to simply create a separate account for each instance of the service. As for why it's failing, it's not clear from your description. But if you use ktpass.exe for example, I don't think you can generate a keytab file with multiple keys (for each SPN) so whenever you set the password using ktpass that will immediately invalidate any previously generated keytab. > but there are numerous examples on > the web of this being done e.g. with a single "http" account and > multiple "http/ip-addr..." SPN's for multiple web servers on your > network. But they're for the same service instance. So one service -> one service account. > Am I right in thinking what I'm trying should be possible, and if so > is there some nuance of generating the keytab that I'm not following > that causes the first keytab to stop working? In theory I think you might be able to generate a single keytab file that has all of the required SPNs. But you would have to use something like ktutil and set the password separately on Windows using the conventional way and not ktpass and also manually add the SPNs. It's probably not worth it. And you might not even be able to do it. One of the Kerberos gurus might be able to tell you how. Again, just create separate accounts and be done with it. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Aqcuiring a TGT for a host/ principal using Active Directory
On Wed, Apr 8, 2009 at 12:54 PM, John Hefferman wrote: > Dear All, > > The problem was definitely related to the bug with SP1, as after > applying the hotfix and specifying +DesOnly when running ktpass, kinit > -kt works fine. I don't know why you should have to specify DES. The default of RC4 should work just fine unless you're using a very old Kerberos library on the client. Or maybe you accidentally specified in your krb5.conf that only DES enctypes should be used? DES is basically deprecated. If I'm not mistaken I think Heimdal has actually removed DES support. You're setting yourself up for a migration migraine. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: confusion with service principal names in Active Directory
On Mon, Mar 30, 2009 at 1:23 PM, John Jasen wrote: > Paul Moore wrote: >> use adsiedit (GUI) to set the spn on the AD rpincipal >> or setspn cli tool > > I don't think that's the problem. The SPN is listed in Active Directory, > and can be queried through ldapsearch, listed via setspn, seen through > ADSIedit or jxplorer, etc. Its definitely in there, just stock kerberos > doesn't see it for some reason. Make sure that you do not have the same SPN set on more than one account. If you do, AD will consider the request ambigous and it will NOT grant a ticket for that SPN. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: WS-Security and GSS-API: How do I get the session key?
On Thu, Mar 5, 2009 at 9:29 PM, wrote:
> Hi Luke
>
> On Feb 24, 9:36 pm, Luke Howard wrote:
>> > I don't recall offhand if there's been an IETF draft proposing the
>> > specific extension we've got for extracting the session key.
>>
>
>> major = gss_inquire_sec_context_by_oid(&minor,
>> ctx,
>> GSS_C_INQ_SSPI_SESSION_KEY,
>> &skey);
>
> Cool, we (Java SE Team at Sun) are also preparing to add a new method
> getSessionKey() to OpenJDK's JGSS-API for Java EE needs.
I think it would be better to have a GSSContext method that could
return an Object that is specific to the OID supplied. For example, in
the case of the session key, it would return a byte[] array like:
Oid sspiSessionKeyOid = new Oid("1.2.840.113554.1.2.2.5.5");
byte[] sessionKey = (byte[])ctx.inquireSecContextByOid(sspiSessionKeyOid);
Otherwise you're going to end up just adding more methods in an
already overwhelming API.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos <-> Microsoft Active Directory & DNS
On Thu, Jan 29, 2009 at 10:00 AM, Christopher D. Clausen wrote: > Michael B Allen wrote: >> In general, both the MIT and Heimdal clients are not optimized for a >> Windows environment. We have an AD integration product that uses >> Heimdal that we made a lot of changes to try to better emulate Windows >> behavior. > > Please just stop trying to sell folks your product using this list. Christopher, No were did I link to or even name the product you speak of (nor do I think it would apply to him) and obviously the solution cited in my signature does not apply to him. I was simply informing him, as someone with real experience in these matters, that AD clients exhibit very different behavior from both MIT and Heimdal and thus he may have to take additional care to compensate. I have mentioned my Kerberos product on this list in the past but only when the list member specifically asked about the unique combination of things to which it applies. All of the changes made to Heimdal that I cited have been posted on the Heimdal mailing list. I have made contributions to the Kerberos community in the form of bug fixes, support and documentation. I do not think my behavior in this thread warranted a complaint. I absolutely did not intend to impress my products on Morten and I was only genuinely trying to help him. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos <-> Microsoft Active Directory & DNS
On Wed, Jan 28, 2009 at 4:57 PM, Morten Sylvest Olsen wrote: > On Jan 28, 9:27 pm, Michael B Allen wrote: >> Hi Morten, >> >> It's not clear to me what component is doing a reverse lookup. What >> software is actually getting the name mixed up? Is it an LDAP client? >> What LDAP client with what Kerberos implementation? What exactly is >> the hostname that you are using with said client? You're not using an >> IP address where an FQDN hostname should be right? > > No, I am not using numeric addresses. I think it happens inside the > Kerberos implementation, it correctly retrieves a tgt for the sub- > domain using my TGT for the base domain, but fails when it tries to > get the service ticket. I can see the wrong principal used in the _REQ > packet (using wireshark). > > It could be the cyrus-sasl GSSAPI plugin as well. (The stack is > openldap -> SASL -> GSSAPI -> Kerberos). > >> I'm not aware of any software that uses a reverse lookup to change the >> hostname before composing the principal name used to request a ticket >> (I would not be surprised if such a thing existed but if it did I >> would consider it broken). > > Well, this is MIT Kerberos (on Linux). The MIT Kerberos libraries uses > DNS reverse lookup for canonization in many places, afaik. I know more about Heimdal than I do MIT so I don't really know how MIT actually uses DNS reverse lookups to discover names. But if I had to guess I would be surprised if it didn't use reverse lookups only as a last resort in the absence of sufficient information in either the krb5.conf or derived from DNS (someone familiar w/ the MIT implementation please step in and correct me if necessary). You might want to make sure your client's krb5.conf has information about all of the domains involved. > Obviously, that is not the case for AD, I have no idea how Heimdal > behaves. I'm still not really sure what the codepath and point of failure is in your use-case so I still can't give you a definitive answer. But Windows clients do use DNS SRV queries A LOT to discover services. That could be related to your issue. In general, both the MIT and Heimdal clients are not optimized for a Windows environment. We have an AD integration product that uses Heimdal that we made a lot of changes to try to better emulate Windows behavior. > I guess your Java implementation doesnt either, judging from > your statements :) The Java solution referenced in my sig is actually NTLM (although that product will eventually also support Kerberos too). Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos <-> Microsoft Active Directory & DNS
On Wed, Jan 28, 2009 at 5:38 AM, Morten Sylvest Olsen wrote: > Hi, > > I have an issue integrating Kerberos to AD. I believe they have an > error in their DNS setup (based on the amount of trouble I've had > through the years with Active Directory and DNS, yuck), but I'd like a > second opinion, before I yell at the AD admins. > > The problem is that a number of AD servers in a sub-domain/sub-realm > resolves to a name in a higher-level domain when doing a reverse > lookup. > > Ie. ad1.ext.domain.org -> 1.2.3.4 > When doing a reverse lookup on 1.2.3.4 I'd get ad1.domain.org > > This fools Kerberos and it tries to get a key for ldap/ad1.domain.org > instead of ldap/ad1.ext.domain.org (MIT Kerberos 1.6.1 on redhat linux > 5) > > I can workaround by messing with /etc/hosts, of course. > > Does anyone know whether this is a "supported" configuration for > Kerberos? Hi Morten, It's not clear to me what component is doing a reverse lookup. What software is actually getting the name mixed up? Is it an LDAP client? What LDAP client with what Kerberos implementation? What exactly is the hostname that you are using with said client? You're not using an IP address where an FQDN hostname should be right? I'm not aware of any software that uses a reverse lookup to change the hostname before composing the principal name used to request a ticket (I would not be surprised if such a thing existed but if it did I would consider it broken). Of course if you supplied an IP address instead, the client would have to do a reverse lookup and that would certainly explain the behavior you see (which I think I might still consider broken). Or perhaps the client cannot resolve the hostname that was supplied and there is some fallback code that is doing a reverse lookup (which again I think I might still consider broken)? Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: mod_auth_kerb: gss_accept_sec_context() failed
On Tue, Jan 20, 2009 at 3:20 PM, Michael Ströder wrote: > [debug] src/mod_auth_kerb.c(1247): [client 10.1.1.5] Acquiring creds for > HTTP/nb2.stroeder.lo...@dom2.adtest.local > [debug] src/mod_auth_kerb.c(1392): [client 10.1.1.5] Verifying client > data using KRB5 GSS-API > [debug] src/mod_auth_kerb.c(1408): [client 10.1.1.5] Client didn't > delegate us their credential > [debug] src/mod_auth_kerb.c(1108): [client 10.1.1.5] GSS-API > major_status:000d, minor_status:96c73a1f > [error] [client 10.1.1.5] gss_accept_sec_context() failed: Unspecified > GSS failure. Minor code may provide more information (, Decrypt > integrity check failed) The "Decrypt integrity check failed" error means that the GSS service located an entry in the keytab file with the target SPN but the encryption key, key version number or encryption type was not exactly the same as that used to encrypt the service ticket. If this error occurs while you're trying to install or update the HTTP service account, it's a good bet that the cause is an old cached HTTP service ticket on the client. Meaning the cached ticket was encrypted with an old encryption key, key version number, encryption type combination. To fix this problem, you simply need to purge your client credential cache (such as by logging off and back on) or wait long enough for the ticket to expire. That will force the client to reacquire a new ticket generated with the most current encryption key, key version number and encryption type. One tool that is helpful with examining your client credential cache and with purging tickets is the kerbtray.exe utility from the Resource Kit Tools package available through MS' website. Run kerbtray.exe and then right click on it's bright green systray icon and select "purge tickets". Whenever you run ktpass it's usually a good idea to purge your client's tickets. If this does not solve your problem then you should run ktpass again and note the encryption key and key version number (the encryption type should be the default which is RC4). Then recopy the keytab and verify with ktutil that the encryption key and key version number are in fact correct. To get delegation to work with Firefox, you must go into about:config and add the servername or domain name to network.negotiate-auth.delegation-uris property. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: computer account change password with Windows 2008 domain
On Wed, Jan 7, 2009 at 1:45 PM, Russ Allbery wrote: > Michael Engemann writes: > >> we are also experiencing the bug in Windows Server 2008 that was >> mentionend on this list in April 2008 by Russ Allberry: >> >> * Microsoft broke password changes via the LDAP protocol with SASL GSSAPI >> binds in Windows 2008. In Windows 2003, provided that you didn't try to >> negotiate an SASL privacy layer, you could connect via TLS and >> authenticate with GSSAPI and query or set the password attribute >> directly. In Windows 2008, this no longer works; you always get the >> error from the server that you are not permitted to negotiate a privacy >> layer when using TLS, even though you're not trying to. We've already >> filed this as a bug. >> >> Are there probably any news about a fix or a known workaround? > > The workaround is to use the password change protocol instead of using > LDAP. That's what we modified our code to do, since so far as I know > Microsoft still hasn't fixed this bug. (Their negotiation of GSSAPI > privacy layers in their LDAP implementation is oddly broken in ways that > are apparently difficult to fix, leading the server to think that you've > always negotiated a privacy layer even if you haven't. At least that's > my understanding of the problem.) Russ, Do you know if works when SASL confidentiality is used instead of TLS? Is there any method that works at all? I'm sure a lot of people would like know exactly what privacy establishment methods allow you to set unicodePwd over LDAP. Fortunately our product has always used the KPASSWD protocol for password setting, password changing and generating keytabs but I had also planned to offer LDAP password setting as an option. Hopefully there are other methods that work without TLS (TLS is kind of a pain anyway). Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos protocol transition for linux?
On Wed, Nov 19, 2008 at 11:45 AM, S2 <[EMAIL PROTECTED]> wrote: > Michael B Allen wrote: >> If you have PHP see the link in my sig about Plexcel. It certainly >> could do what you describe. > > The back end services are a mix of Java, .NET, php and rails apps (on > windows and on linux servers), so the proxy should be language > independent and not require a module on the application server side. > I am not sure I understood from the pdf how Plexcel works. > All application servers can already speak SPNEGO, so that should be used > to forward the Kerbeos credentials over HTTP (I did read SPNEGO on that > page, but I am not sure how it is used). > So what we would like to do is (fixed font required): > >O > \|/ +-+ +---+ >| ---> | Magic proxy | --> | Protected Service | > / \ HTTP +-+ SPNEGO +---+ > User^ > from the | > Internet | > v > +-+ > | KDC | > +-+ > > Do you think Plexcel could be the "Magic Proxy" Box? Actually yes, I think Plexcel would work quite well for this. Basically you would just write a PHP script that presented a logon form and then used plexcel_logon [1] to associate the TGT with the user's session ID. You'll need to use the putenv_krb5ccname option with plexcel_new [2] so that the TGT is saved in a ccache file in the plexcel/tmp directory. Once you have their TGT in a ccache file, you can use an SPNEGO capable HTTP client like the cURL extension. In the plexcel/examples directory, there's actually an example script that uses the delegated TGT to query another SPNEGO protected page using cURL (note that unlike Plexcel, using cURL to do SPNEGO requires a valid local /etc/krb5.conf). Then you just need to look at the hostname (or whatever you're using to address second tier requests), build a cURL request with the original request input, send it to the corresponding service and redirect the output of cURL back to the client. Plexcel would also allow you to add nice access control at the proxy level. Note that you'll be invoking a PHP script with each request. Even though Plexcel is fast and SPNEGO with the second tier is the elephant in the room, a raw pure C proxy like Squid would give you better throughput (albeit with less flexability). In practice I think your level of awareness wrt protocol details like pipelining, chunked responses, etc will be the important to real world performance of the solution. But at the very least, building your "Magic Proxy" with Plexcel would be an easy way to determine if it is possible and how it can be done in an optimal way. Then you can worry more about performance. Your "Magic Proxy" idea is actually very interesting. One nice thing about it is that I suspect the script itself should be no more than a few hundred lines of code in one file. If it really works, send it my way and maybe I'll tweak it up and support it like the Plexcel plugins for Joomla! and MediaWiki (note these plugins are good examples of how to use Plexcel correctly). [1] http://www.ioplex.com/api/plexcel_logon.html [2] http://www.ioplex.com/api/plexcel_new.html >> PS: The '.invalid' address in your email actually stops gmail from >> sending directly to you. You might want to try a valid TLD. > > That email account is not valid anyway. I know but I'm saying gmail actually pops up a dialog that complains the address is invalid. I have to actually remove the bogus address before I can send. If you used @ndom.mail.invalid.net you might improve your chances of getting responses. Also we're drifting off topic with this thread. Contact me directly with your real address if you have any further questions. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos protocol transition for linux?
On Tue, Nov 18, 2008 at 4:21 PM, S2 <[EMAIL PROTECTED]> wrote: > Hallo all! > In our small corporate we decided some time ago that in our intranet > "all" (when possible) services we write should use kerberos to > authenticate the users. This way we can have a central location to store > all identities and we can propagate the user identity from service to > service using forwardable tickets (well... this is what kerberos was > designed for :)). > As it happens to be, some of our applications need to be accessed from > the evil internet, and the users accessing them can't access our KDC to > get a TGT, so we use Microsofts ISA server to make the transition from > Forms Based authentication to kerberos tickets. Let me explain this part > just to be sure we are talking about the same stuff: ISA shows the user a > form asking for a username and a password, uses this credentials to get a > TGT from the KDC and then uses that ticket to authenticate to the > applications in our intranet on behalf of the user. ISA keeps a list of > SSO-Cookie-Values and kerberos tokens, so it can talk cookies to the user > and kerberos to the backend applications. > Now my question: is there something like this for linux? If you have PHP see the link in my sig about Plexcel. It certainly could do what you describe. Mike PS: The '.invalid' address in your email actually stops gmail from sending directly to you. You might want to try a valid TLD. -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: IE6 Fallback to NTLM
On Mon, Nov 10, 2008 at 4:06 PM, Jobo <[EMAIL PROTECTED]> wrote: > IE (6) and Kerberos > > At some (actually one) locations in our network (which is spread all > over the Netherlands) we have the problem that IE6 randomly falls back > to NTLM, while FF keeps on working flawlessly. > > Does anybody has a clou what is happening? Tickets are valid and > available, and when a new instance of IE is opened, everything works OK > again. > > The facts: > Server: SLES 10 + Apache + mod_auth_kerb (Kerberos 5 release 1.4.3) > Client: IE6 on XP > Tickets are served by Active Directory. In the past there have been a few bugs in cache handling on XP: http://support.microsoft.com/kb/906524 http://support.microsoft.com/kb/885887 Check your kerberos DLLs. But I haven't seen anyone complain about these sorts of things in a while so I'm not sure if the bugs described in these KBs are really relevant anymore. Note that FF can exhibit different behavior depending on how it's configured. Note that for some strange reason, FF on Linux actually requests a service ticket with each HTTP request even though it has a perfectly good one in the cache. So make sure you're testing FF on Windows if you want a fair comparison. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: No principal in keytab
On Thu, Oct 30, 2008 at 10:47 AM, yuval <[EMAIL PROTECTED]> wrote: > Hi > > > > I try to authenticate web server clients on Linux apache. > > > > I have keytab from win2003 and kinit pass OK. > > > > Klist show valid principal. > > [EMAIL PROTECTED] klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: > HTTP/[EMAIL PROTECTED] > > > > Valid starting ExpiresService principal > > 10/30/08 14:50:28 10/31/08 00:50:46 > krbtgt/[EMAIL PROTECTED] > >renew until 10/31/08 14:50:28 > > > > > > Kerberos 4 ticket cache: /tmp/tkt0 > > klist: You have no tickets cached > > > > > > but I got gss error "No principal in keytab matches desired name" What is the URL you are using the address bar of the browser? The hostname in the URL must match the hostname in the principal name in the keytab file exactly. For example, if you use an IP address to visit the website, you will get the aforementioned error. List the contents of the keytab file with ktutil. Are you sure the keytab file is being successfully ready by Apache? Mike Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos fallback
On Thu, Oct 16, 2008 at 9:16 PM, Lim, Melvin <[EMAIL PROTECTED]> wrote: > Hi > > I would like to double confirm where did the Kerberos fallback to NTLM > taking place, > > > > 1. The fallback taking place while negotiation > > 2. The fallback taking place after the negotiation Hi Melvin, First, you should realize that you're asking about a largely Microsoft Windows specific issue whereas this is a Kerberos-only mailing list (albeit gracious to MS specific questions). Other than both being authentication protocols, NTLM and Kerberos are not related. Anyway, the answer to your question is option "0". Meaning a Windows client will fall back to NTLM if it cannot perform Kerberos for any reason. That evaluation occurs before any "negotiation" with the target. Specifically, when a Windows client decides that it is to perform SSPI style authentication, it tries to acquire a Kerberos ticket for the desired service. There are a number of points where that acquisition can fail. The client may not be joined to the domain, it may not have adequate communication with the KDC, the service account may not be setup correctly, etc. If any of these things fail, the client will then try NTLM. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Sequence numbering after export and import of context
On Mon, Oct 6, 2008 at 3:11 PM, Markus Moeller <[EMAIL PROTECTED]> wrote:
> I haven't used much shared memory. How would it work with shared memory ? I
> would have thought gss_init_sec_context/gss_accept-sec_context just gets a
> pointer and the underlying gss functions allocate the memory somewhere, not
> necessarily in the shared memory area ? How can you force the gss functions
> to use the shared memory ?
Hi Markus,
I'm not talking about putting GSS objects in shared memory (although
it would be dandy if it accepted allocator functions so that that were
possible). The model I'm talking about is quite different from what
you're doing and would require significant reorganization. The model
I'm talking about uses one process dedicated to doing all socket IO
(the "muxer" process) and thus would handle any gss_{wrap/unwrap}
without any context exporting / importing. Now a caller process can
allocate a shared memory buffer, write the message into it and signal
the muxer to take over, write it, read the response and finally notify
the calling process (this isn't exactly how our code works, it's
actually much more complex but the idea is the same).
Anyway, from what I've read in this thread, provided things are
serialized properly, I think what you're doing should work. The
problem could very well be that the export/import feature is a code
path less travelled so there could be bugs. Are you using MIT or
Heimdal or ...?
Mike
> "Michael B Allen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On Sun, Oct 5, 2008 at 10:38 PM, Nicolas Williams
>> <[EMAIL PROTECTED]> wrote:
>>> On Sun, Oct 05, 2008 at 11:13:00PM +0100, Markus Moeller wrote:
>>>> Thank you for the replies.
>>>>
>>>> I get an GSS: error: "The token was a duplicate of an earlier token" and
>>>> debugging on the client shows that it received seq 0 but expected 1. So
>>>> I
>>>> need to dig a bit further what my server processes do. Is the following
>>>> OK :
>>>>
>>>> client <-> server main process establishes context -> export_context
>>>> client <-> child 1 import_context -> unwrap + wrap (seq 0) ->
>>>> export_context
>>>> client <-> child 2 import_context -> unwrap + wrap (seq 1)-> cleanup
>>>
>>> Do I understand correctly that you're importing a given exported
>>> security context token twice?
>>>
>>> If so, then "no, that's not supported." RFC2743 is quite clear on this.
>>>
>>> And it makes sense too: there may be no way for "child 1" and "child 2"
>>> to keep their sequence number windows in sync and perform as well as if
>>> they did not even try to keep them in sync. Also, the spec allows the
>>> second GSS_Import_sec_context() function call to fail, and it is
>>> possible to imagine implementations where such a failure would occur.
>>>
>>> Heck, even if an implementation supported multiple imports of one
>>> exported security context token you'd still have problems because
>>> whatever the per-message token sequence number window size is, if one
>>> process consumes/produces per-message tokens at a sufficiently different
>>> rate than the other then you'll still get sequencing errors.
>>>
>>> You could cheat and not request sequencing, but there's no guarantee
>>> that that will work either -- as long as you're importing the same
>>> exported security context token more than once then you're in trouble,
>>> and if it works it will be an accident of the mechanism's implementation
>>> and so your application will not be portable.
>>
>> Personally I think the whole export / import of security contexts is a
>> little awkward. Instead of moving the context we just put all IO
>> buffers in shared memory and have one process running the muxer loop
>> (although the reason for doing this has nothing to do with GSSAPI).
>>
>> Mike
>>
>> --
>> Michael B Allen
>> PHP Active Directory SPNEGO SSO
>> http://www.ioplex.com/
>>
>> 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
>
--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Sequence numbering after export and import of context
On Sun, Oct 5, 2008 at 10:38 PM, Nicolas Williams <[EMAIL PROTECTED]> wrote: > On Sun, Oct 05, 2008 at 11:13:00PM +0100, Markus Moeller wrote: >> Thank you for the replies. >> >> I get an GSS: error: "The token was a duplicate of an earlier token" and >> debugging on the client shows that it received seq 0 but expected 1. So I >> need to dig a bit further what my server processes do. Is the following OK : >> >> client <-> server main process establishes context -> export_context >> client <-> child 1 import_context -> unwrap + wrap (seq 0) -> >> export_context >> client <-> child 2 import_context -> unwrap + wrap (seq 1)-> cleanup > > Do I understand correctly that you're importing a given exported > security context token twice? > > If so, then "no, that's not supported." RFC2743 is quite clear on this. > > And it makes sense too: there may be no way for "child 1" and "child 2" > to keep their sequence number windows in sync and perform as well as if > they did not even try to keep them in sync. Also, the spec allows the > second GSS_Import_sec_context() function call to fail, and it is > possible to imagine implementations where such a failure would occur. > > Heck, even if an implementation supported multiple imports of one > exported security context token you'd still have problems because > whatever the per-message token sequence number window size is, if one > process consumes/produces per-message tokens at a sufficiently different > rate than the other then you'll still get sequencing errors. > > You could cheat and not request sequencing, but there's no guarantee > that that will work either -- as long as you're importing the same > exported security context token more than once then you're in trouble, > and if it works it will be an accident of the mechanism's implementation > and so your application will not be portable. Personally I think the whole export / import of security contexts is a little awkward. Instead of moving the context we just put all IO buffers in shared memory and have one process running the muxer loop (although the reason for doing this has nothing to do with GSSAPI). Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Sequence numbering after export and import of context
On Sun, Oct 5, 2008 at 7:51 AM, Markus Moeller <[EMAIL PROTECTED]> wrote: > I have an application which initializes the security context in one process > does some gss_wrap/gss_unwrap calls and then exports the context to hand it > over to another process which imports the context and continues the > gss_wrap/gss_unwrap. Would the second process restart sequencing at 0 or > continuing from where the context was exported ? I'm not even going to try to come up with a citation but common sense would suggest that an imported GSS context must use the sequence number of the exported context and must never reset the sequence number to 0. I don't see how the peer could even know that the sequence number was reset. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using LDAP backend with start_tls
On Wed, Sep 17, 2008 at 5:21 PM, Klaus Heinrich Kiwi <[EMAIL PROTECTED]> wrote: > Hi everyone, > > I was wondering how can I use the LDAP backend over a TLS connection. > Looking at the krb5.conf file man page, looks like there is no option > covering this and I'm assuming that simply using ldaps:// as the > ldap_servers URI will toggle SSL over port 636 instead of TLS at port > 389. > > ldapi://socket will initiate a unix socket connection > ldap://host will start an unsecured connection at port 389 > ldaps://host will start SSL through port 636 > > Is there a way to START_TLS over port 389? Perhaps you can grep through the ldap backend source. If it uses OpenLDAP's API I believe the function in question is called ldap_start_tls_s. If it exists, maybe you can determine what conditions are required to trigger it. Or wait for someone to answer who actually knows how the LDAP backend works :-> Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [modauthkerb]: KRB5CCNAME only set for subprocesses
On Wed, Sep 17, 2008 at 8:25 AM, Andreas Roth <[EMAIL PROTECTED]> wrote: > Hello, > > i'm using mod_auth_kerb version 5.3 (from ubuntu intrepid) and apache2 on a > ubuntu hardy machine. I set up the kerberos authentication using mod_auth_kerb > and it works well, but i have one problem: When i use a CGI-Script (e.g. shell > script) set environment variable KRB5CCNAME is set, but when i use a PHP- > Script (just calling phpinfo() ) the environment variable is not set. > Is this the correct behaviour? I would like to use the kerberos cache within > my PHP scripts; how can i do this? Andreas, I don't have a definitive answer for you but here are a few thoughts: Try adding KRB5CCNAME to the safe_mode_allowed_env_vars INI property. However, instinct tells me this is probably not the problem. Note that the $_ENV global and getenv() function can return different results - try running a simple script that uses getenv instead to see if KRB5CCNAME is set. I have a feeling this is going to be the issue which is to say there is no issue since any Kerberos aware client will use getenv(). Also, I think you have to set a mod_auth_kerb option to indicate that you want KRB5CCNAME set (although apparently you have already done this if it works under a cgi script). Finally, if your KDC is AD you might want to checkout our Plexcel product (see signature). Plexcel for PHP does SPNEGO or explicit Kerberos logons, delegation, script-level group based access control, setting / changing passwords, account management w/ name canonicalization, "Sites and Services" support, DNS caching, redundancy / fail-over, support for multiple SPNs in your keytab for virtual hosting, plugins for popular PHP applications and more. Many of these details are impossible or very difficult to implement with the standard OSS stack. Anyway, if you try Plexcel or have any questions about it, please contact IOPLEX Software support directly and I'll help you in whatever way I can. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: spnego
On Tue, Sep 16, 2008 at 4:15 PM, Tuomas <[EMAIL PROTECTED]> wrote: > Michael B Allen wrote: >> On Thu, Sep 11, 2008 at 12:30 PM, Tuomas >> <[EMAIL PROTECTED]> wrote: >>> I also found out using wireshark what Internet Explorer does when it >>> fails to authenticate using Kerberos. It asks a ticket from the Active >>> Directory server for HTTP/virtualhost.domain.com instead of >>> HTTP/realname.domain.com. For me this seems like a bug in IE7, has >>> anyone found solutions for this? >> >> That's not a bug. You will need to add SPNs to the desired account >> (using setspn) for each virtual hostname. > > I see, just can't understand why this is happening occasionally. At > least it makes things harder. > > Anyway, I set up "setspn -a HTTP/virtualhost.domain.com", things still > didn't work as they should. Now i apache's error.log I get: > gss_accept_sec_context() failed: Unspecified GSS failure. Minor code > may provide more information (Key table entry not found) > > I understand that I should have also virtualhost.domain.com defined in > my keytab, just don't have any idea how to do that. Actually I think I might know why you're getting an error (I don't know a lot about mod_auth_kerb - I know a lot more about what is possible protocol-wise as opposed to what mod_auth_kerb can do). A keytab file can have multiple principals (SPNs in this case). For example, our Plexcel product automatically generates a keytab with all of the SPNs set on the HTTP service account. But now that I think about it, because mod_auth_kerb relies on ktpass.exe to generate the keytab file, and because ktpass can only generate the said keytab file with one principal, it has to be that one SPN you want to use. Meaning I suspect you have to run ktpass to generate a keytab file *with the specific SPN* you want to use. You might want to bring your problem to the mod_auth_kerb mailing list. They would certainly know better than I how to set this up. I'm happy to give you my best guess here but again, I'm not terribly familiar with mod_auth_kerb's nuances. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: spnego
On Thu, Sep 11, 2008 at 12:30 PM, Tuomas <[EMAIL PROTECTED]> wrote: > I also found out using wireshark what Internet Explorer does when it > fails to authenticate using Kerberos. It asks a ticket from the Active > Directory server for HTTP/virtualhost.domain.com instead of > HTTP/realname.domain.com. For me this seems like a bug in IE7, has > anyone found solutions for this? That's not a bug. You will need to add SPNs to the desired account (using setspn) for each virtual hostname. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Application to extract Kerberos Cerdential
On Wed, Sep 10, 2008 at 3:59 PM, Rahul Kohli <[EMAIL PROTECTED]> wrote: > Hi Henry, > > Thanks for your response. > > This C application (shared library) will be used for validating the kerberos > credential of a user with KDC on Microsoft AD 2003. > > Please suggest how we can use/develop a C application to validate user's > kerberos credentials with KDC located on different system. You don't need to communicate with the KDC to validate the Kerberos token supplied by an HTTP client. You only need to use the service credential to decrypt the authenticator in the token and verify that the timestamp is within an acceptable range. And, depending on the system you're using, there are C routines that will perform all of these details for you. For example, UNIX systems usually come with a library called GSSAPI that have a gss_accept_sec_context function that does what you want. Sometimes GSSAPI is part of the Kerberos installation (e.g. on Linux GSSAPI usually comes with the MIT Kerberos packages). On Windows, there's something called SSPI which has a very similar function called AcceptSecurityContext. Mike > --- On Wed, 9/10/08, Henry B. Hotz <[EMAIL PROTECTED]> wrote: > > From: Henry B. Hotz <[EMAIL PROTECTED]> > Subject: Re: Application to extract Kerberos Cerdential > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Date: Wednesday, September 10, 2008, 10:45 PM > > On Sep 10, 2008, at 9:17 AM, [EMAIL PROTECTED] wrote: > >> Message: 1 >> Date: Wed, 10 Sep 2008 07:05:39 -0700 (PDT) >> From: Rahul Kohli <[EMAIL PROTECTED]> >> Subject: Application to extract Kerberos Cerdentials >> To: [EMAIL PROTECTED] >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset=iso-8859-1 >> >> Hi All, >> ? >> I am using Kerberos Client installed on HP-UX with?Active Directory >> 2003 (KDC Server).?I have verified the setup to be?working fine >> using Kinit and Klist utilities installed with Kerberos Client. >> ? >> I need to develop a sample C/C++ application that can extract User's >> kerberos credentials from the browser HTTP request and pass it to >> Kerberos Client for validation with KDC Server. >> ? >> Please suggest how can we extract user's kerberos credentials from >> Browser. Where can I get details of the API's to be used for this >> purpose. >> ? >> Thanks, >> Rahul >> ? > > I think this kind of question belongs on the kerberos@mit.edu list, > since it's not specific to the MIT implementation. I've set the reply- > > to header accordingly. > > I don't understand the application you're proposing. Is it possible > that what you want is really a web server module like mod_auth_kerb? > I can't imagine why you would want a *browser* to check a user's > credentials because the user owns the browser and can run whichever > one he/she wants, including a custom-modified one. > > For the normal usage scenarios the "extraction" process happens > automatically as part of some other task. If you can tell us what > you're trying to do, then perhaps we can point you at the right API's. > ___ > krbdev mailing list [EMAIL PROTECTED] > https://mailman.mit.edu/mailman/listinfo/krbdev > > > > > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberize MS Exchange?
On Thu, Sep 4, 2008 at 2:26 PM, Eric Hill <[EMAIL PROTECTED]> wrote: >> Kerberize it how? >> >> MS Exchange uses a proprietary communications protocol so it's not >> clear how Kerberos authentication even works in Exchange [1]. >> >> If you're talking about using IMAP4, last I checked MS Exchange does >> not support Kerberos w/ IMAP4 at all. >> >> Mike >> >> [1] There is some new "Exchange Protocols" documentation released as >> part of the EU settlement that might include such details. > > Actually the protocol doesn't really include anything for authentication. > The core Exchange security mechanism is a named pipe > connection to the server, and a thread running ImpersonateNamedPipeClient on > the server-side to handle requests on behalf of the > user. > > Microsoft may or may not use Kerberos to authenticate the pipe. I understand. That's good actually because there is quite a bit of open code that can do Kerberos over Windows named pipes (including SMB named pipes). Incidentally, I have been informed off-list that newer versions of Exchange's IMAP implementation actually do support Kerberos via GSSAPI. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberize MS Exchange?
On Thu, Sep 4, 2008 at 8:13 AM, Walter Sobchak <[EMAIL PROTECTED]> wrote: > I'd like to kerberize ms exchange. I found some information about adding > a security patch and some settings but not enough for it to work. > Are there any pointers someone could give me? > Do I have to use some commercial solution or it can be configured or > programmed manually? Kerberize it how? MS Exchange uses a proprietary communications protocol so it's not clear how Kerberos authentication even works in Exchange [1]. If you're talking about using IMAP4, last I checked MS Exchange does not support Kerberos w/ IMAP4 at all. Mike [1] There is some new "Exchange Protocols" documentation released as part of the EU settlement that might include such details. -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using GSSAPI to Authenticate to AD
On Thu, Aug 28, 2008 at 9:12 AM, <[EMAIL PROTECTED]> wrote: > - Now, how do I initialize the security context for userB if my > process is running in root's context? > > I found one more thread about this : > http://groups.google.co.in/group/comp.protocols.kerberos/browse_thread/thread/434a62ca2c65876d/9d3d8914af3befd4?hl=en&lnk=st&q=%22gss_krb5_ccache_name%22#9d3d8914af3befd4 > > As mentioned in the thread above, it is possible to switch to > different user security context using gss_krb5_ccache_name. There are > problems there as well though: > > - If you want switch user contexts multiple times, in multiple > threads, application's performance gets affected because initializing > security context (or one of the steps in it) is a lengthy operation - > on my setup it takes almost 5 seconds. > - I believe the switch has to be synchronized so that unless > gss_init_sec_context in one thread completes, I cannot call > gss_krb5_ccache_name from anywhere else in my application - that > increases the delay in multi threaded application even more. > > That was the reason why I wanted to know whether gss_init_sec_context > somehow accepts a local parameter so that initializing security > contexts of different users can be indepenent of each other. The gss_init_sec_context function accepts a gss_cred_id_t parameter that represents the initiator credential. This credential can be obtained for an arbitrary account using the gss_acquire_cred function provided a credential for the desired account is available for the target mechanism. There is no need to change your identity with setuid unless you will be performing local operations that require the identity be a certain local account. GSSAPI has no knowledge of local accounts and never looks at the default identity of the user (however if no gss_cred_id_t is supplied at all, the underlying mechanism may use the local identity to guess where it might find credentials). Meaning, you want to export the KRB5CCNAME environment variable to point to a ccache file with credentials for the desired account. This assumes of course that there is such a credential. Unfortunately GSSAPI does not define how to acquire initial credentials. Like I said - there are a lot of details that are not handled by GSSAPI alone. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using GSSAPI to Authenticate to AD
On Wed, Aug 27, 2008 at 4:53 AM, <[EMAIL PROTECTED]> wrote: > Hi, > > I want to authenticate an Active Directory User using GSSAPI. The code > would be in C++. To be specific here is the scenario: > > 1] End user adopts/creates one or more Active Directory users using > any of the AD integration packages on Linux. > 2] In my executable, which would be always running as root, I find out > that I need to use AD user and authenticate using GSSAPI > 3] I cannot impersonate as the user because that would change user > context of whole process. > 4] Therefore, I need to somehow find out whether there is already a > ticket for that user available (Win32 SDK: AcquireCredentialsHandle, > GSSAPI: GSSAPI::Name->import?) > 5] If not, process would obtain one. > 6] Get the ticket and initialize the security context (Win32SDK: > InitializeSecurityContext, GSSAPI: GSSAPI::Context::init?) > 7] Get the token and send it for authentication > > If the process is running in the user context which needs to be > authenticated, it's easier and I have perl implemenation of it. But in > this case, since process will always be running as root, I don't know > if there is a way I can know/get ticket for authentication. > > Is there a sample/example that can, at least in parts if not > completely, illustrate how this can be done using C/C++ somewhere? > > I found one link on MSDN but don't know whether that's the entire flow/ > applicable: http://msdn.microsoft.com/en-us/library/ms995352.aspx > > Any comments would be welcome. GSSAPI just handles authentication. That's not terribly difficult to do in C++ but it's not clear how you get from GSSAPI authentication to creating users "using any of the AD integration packages on Linux". There are a lot of details to creating an application like that in Linux. It's a lot harder than it looks. Incidentally there is a product called Plexcel that has worked out all of these details (see the link in my signature - it's also free for up to 25 users). With the Plexcel PHP extension you can easily create a web page that will authenticate someone using SPNEGO (or explicit Kerberos login) and then use the delegated credential to create users, change passwords, etc [1]. Or you can do it from the commandline. In fact I have a very nice little Plexcel commandline script for creating users that a wrote for someone else that I would be happy to give you. If you want a copy, or if you have any questions about Plexcel feel free to contact me directly through IOPLEX Software support. Mike [1] To give you an idea of what the code would look like look at the example on this page: http://www.ioplex.com/api/plexcel_add_object.html -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: spnego
On Sun, Aug 17, 2008 at 3:35 AM, yuval <[EMAIL PROTECTED]> wrote: > Hi All > > I have web server that required authentication. > It does so by returning 401 www-authenticate: negotiate. > IE (FF too) sends Kerberos ticket to authenticate. > > When client (or client machine) is not from domain, IE popup for credential > and create NTLMSSP blob. > > Is any way to continue the negotiation with the IE before it pops up the > NTLM credential to user? May be by sending spengo option? See "Issue 3" in the Plexcel Operators Manual on the Support page of the website in my signature. It outlines all of the reasons for browsers not doing Kerberos (obviously if you are not using Plexcel you will need to ignore any product specific references but getting browsers to do Kerberos is pretty much the same regardless of what you are using on the server side). Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Creating an MIT style keytab for an existing Windows AD member computer
On Wed, Jul 23, 2008 at 3:59 AM, Edward Irvine <[EMAIL PROTECTED]> wrote: > Hi, > > I'd like to find out if there is any way to extract a HOST keytab for > a windows computer that is already a member of an active directory > domain. > > A Java developer I look after wants to do the single sign on thing to > his web application. Our environment is a mixed Active Directory and > Solaris environment. > > By creating a new user in active directory, and mapping the user to a > service principle using ktpass.exe, we now have SPNEGO single sign on > working between the clients Internet Explorer and the JBoss server on > *Solaris*. So far so good. > > The developer, who uses a Windows workstation that is part the Active > Directory domain, now wants the SPNEGO authentication to work in his > own windows workstation - and for that to work I need to get the > keytab for the host/[EMAIL PROTECTED] > > A quick LDAP lookup of his workstation in AD reveals that it already > has a servicePrincipalName of HOST/pingname.of.host - so presumably I > can extract the keytab somehow. But how? > > I don't personally have admin access to the AD domain, but I work > with the folks who do. Extracting the keys from AD is not possible [1]. However, the ktpass utility from MS can set the password, generate the corresponding key separately and put it into a keytab file. Note that you must have at least account operator privilege to set a password in AD. Mike [1] There is a freeware utility called ktexport that can extract the keys from a DC and dump them into a keytab but it is only (sometimes) useful for debugging purposes with WireShark. The resulting keytab is not valid for use with any kind of service. -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Problem with SPNEGO on Solaris 10 build 4
On Sun, Jul 20, 2008 at 11:33 AM, Markus Moeller <[EMAIL PROTECTED]> wrote: > I tried to use my squid_kerb_auth on Solaris 10 and fail. I don't know anything about squid_kerb_auth or Solaris 10 really but how are libs linked together? There are enough GSSAPI and Kerberos libs around that you almost have to use symbol versioning if you're loading things dynamically. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SSO
On Fri, Jul 18, 2008 at 12:03 PM, Michael Ströder <[EMAIL PROTECTED]> wrote: > Simon Wilkinson wrote: >> >> On 18 Jul 2008, at 12:13, Michael Ströder wrote: >>> Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought >>> it's just a service ticket. >> >> SPNEGO is a GSSAPI mechanism, wrapping the Kerberos one. If you set the >> deleg_creds flag when calling into the API, then a TGT will be included. > > Which entity has to set this flag when calling into the API? The web > browser or the web server? It's the client's responsibility to decide whether or not to include a TGT. A client can always request a forwardable TGT in which case it can be submitted to the web server. For example on Linux if you do kinit -f [EMAIL PROTECTED] and then point Firefox at an SPNEGO protected page, and it has network.negotiate-auth.delegation-uris set to the target domain, it will send the TGT. However, if you're using Windows clients in an AD environment and the HTTP service account has "Trusted for delegation" turned off, the TGT will not be sent. > My goal when doing SSO for web applications is that I don't trust the > web applications so much not to reveal the user's credentials. Your choices are based on necessity, not trust. If the web application needs delegated credentials (e.g. to authenticate as the user with another tier), then you need to send the TGT [1]. If the web app does not need delegated credentials then configure your clients not to send the TGT (in AD this means simply turning off the "Trusted for delegation" flag on the HTTP service account). Mike [1] Kerberos provides other ways to limit how the TGT can be used and to proxy service tickets and such but I don't think browsers have support for such things yet. -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SSO
On Fri, Jul 18, 2008 at 7:13 AM, Michael Ströder <[EMAIL PROTECTED]> wrote: > Michael B Allen wrote: >> On Thu, Jul 17, 2008 at 6:46 PM, Russ Allbery <[EMAIL PROTECTED]> wrote: >>>> And that is the scenario where direct SPNEGO / NTLMSSP solutions are >>>> going to perform better. >>> If by "better" you mean "pretty much the same," yes, modulo the >>> configuration note that I mentioned. >> >> No, I definitely meant "better". >> >> With direct SPNEGO we 401 the initial HTTP request, accept one GSSAPI >> token and get a TGT. > > Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought > it's just a service ticket. Yes, the relevant SPNEGO token is basically a wrapped AP-REQ wihch is composed of a service ticket and an authenticator. I believe the TGT or what is used to build a TGT is in the authenticator (at least that's what WireShark calls it). Incidentally the encrypted part of the service ticket contains the authorization data (the PAC if it was issued by AD) which I assume is combined with the TGT data in the authenticator to build a TGT with authorization data. Otherwise it would have to dupe that data and the size of blobs in the SPNEGO token doesn't represent that. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SSO
On Fri, Jul 18, 2008 at 5:28 AM, Simon Wilkinson <[EMAIL PROTECTED]> wrote: > > On 18 Jul 2008, at 06:57, Russ Allbery wrote: > >> "Michael B Allen" <[EMAIL PROTECTED]> writes: >> >>> If you read the whole thread you'd know I'm only talking about the >>> *IntrAnet* scenario. With SPNEGO you do not type in a passwords at >>> all >>> whereas with WebAuth you might need to. >> >> You're making a bogus comparison. > > Russ has pretty much covered the ground here, but I thought I should > make some comments from our (Cosign based) perspective. > > SPNEGO is great in an all Windows environment, where you absolutely > control every client that's authenticating to your system. It breaks > down as soon as you add machines which are only loosely under your > management control. As well as requiring that all clients have a > properly configured Kerberos client, using SPNEGO with Firefox also > requires browser configuration, which has to happen for every site > that users may access, or delegate credentials to, and for every user. As stated before this is completely false. These browser configuration options accept a domain name which makes all the configs the same. You do not need to specify explicit hostnames. AD will not give services TGTs unless the service account is flagged as "Trusted for delegation". > The only fly in the ointment here is that none of the WebSSO > solutions currently available can handle authenticating POST > requests, where the user hasn't previously authenticated to the > service, due to their requirement for redirects. For us, this was a > small price to pay. SPNEGO handles authenticating POST just fine. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SSO
On Thu, Jul 17, 2008 at 9:52 PM, Christopher D. Clausen <[EMAIL PROTECTED]> wrote: >> With Plexcel we can do SPNEGO, check group membership (we extract the >> group SIDs from the PAC), app-level access to basic user info and a >> get TGT without talking to a third party at all. The time between the >> initial HTTP request and the 200 response is less than 20 ms (or ~50 >> ms if the user is in a few hundred groups). > > The whole point of the central server is to keep end-users from typing > passwords in at all the other random webservers. If you read the whole thread you'd know I'm only talking about the *IntrAnet* scenario. With SPNEGO you do not type in a passwords at all whereas with WebAuth you might need to. If you have a lot of clients that cannot do SPNEGO then, yes, WebAuth and Cosign are better solutions. > The point is that those hosting the server are not to be > trusted with the end user passwords and the central server solves this > problem. That's not a problem if you're using AD since you have the "Account is trusted for delegation" flag which is off by default. No one can setup a service and lure people into giving up their TGTs. An admin has to go into the account and flag it as trusted for delegation. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SSO
On Thu, Jul 17, 2008 at 6:46 PM, Russ Allbery <[EMAIL PROTECTED]> wrote: >> And that is the scenario where direct SPNEGO / NTLMSSP solutions are >> going to perform better. > > If by "better" you mean "pretty much the same," yes, modulo the > configuration note that I mentioned. No, I definitely meant "better". With direct SPNEGO we 401 the initial HTTP request, accept one GSSAPI token and get a TGT. With something like WebAuth, the client is redirected to a central server, then you have to do all of the above (or an explicit login which is more stuff) and then redirect the client back to the original target (and this doesn't include getting a TGT on the target server). With Plexcel we can do SPNEGO, check group membership (we extract the group SIDs from the PAC), app-level access to basic user info and a get TGT without talking to a third party at all. The time between the initial HTTP request and the 200 response is less than 20 ms (or ~50 ms if the user is in a few hundred groups). Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SSO
On Thu, Jul 17, 2008 at 5:01 PM, Russ Allbery <[EMAIL PROTECTED]> wrote: > "Michael B Allen" <[EMAIL PROTECTED]> writes: >> and, more important, they do not give you true single-sign-on >> behavior. They're more like "double sign on" because you have to login >> to a central server and they get redirected back to the target site. > > Well, no, they're double sign-on because the central server usually has to > prompt you for a password. But if the central server implements > Negotiate-Auth and the browser speaks it, both WebAuth and Cosign give you > true and complete single sign-on. But only if clients are members of the domain. And that is the scenario where direct SPNEGO / NTLMSSP solutions are going to perform better. >> For a strictly IntrAnet environment the WWW-Authenticate: Negotiate or >> NTLMSSP protocols used by IIS, mod_auth_kerb, Plexcel, JCIFS and >> others are the only true *Single* Sign On solutions where the clients >> existing credentials are used to transparently authenticate without >> requiring the user to enter a password. > > This is true, but somewhat deceptively so, given that WebAuth and Cosign > can both leverage Negotiate-Auth to extend that single sign-on capability > to all web servers without Negotiate-Auth on each one and (often more of > an issue) without having the user have to bless every server for > Negotiate-Auth authentication. (They only have to bless the central login > server.) I believe you mean that you have to add something to "IE > Security > Local intranet" or the "network.negotiate-auth.trusted-uris" in FF? You do not have to specify each server explicitly. Those configs accept domain suffixes. > However, if that configuration issue isn't a concern, simply using > Negotiate-Auth, which is built into IIS, is definitely easier. It does, > however, require that your clients have a local Kerberos configuration > (members of an AD domain, for example) to get single sign-on Of course. You can't have true single sign on if you're not a member of the service's domain (or a domain the service's authority trusts). > and falls > back to essentially basic-auth for each server without it, > whereas WebAuth > or Cosign will fall back to a single web authentication and then reuse of > that authentication without having to further enter your password. The > password prompting behavior from an IIS server to Firefox and similar > browsers is also poor and confusing in our experience, but that may be > fixable. This is a little bit of a stretch. It might be true for mod_auth_kerb but otherwise, it's basically false. IIS will do NTLMSSP if the client does not want to or cannot do SPNEGO. If that fails (e.g. because the client is not logged in with domain credentials) then the browser will pop up a password dialog but it will still do NTLMSSP with the creds entered. At least if you're using IWA it will. Of course IIS to do BASIC but you have to configure it that way and we're not talking about that. In our Plexcel product, we provide a script level API which provides a major advantage over IIS, WebAuth, mod_auth_kerb or anything else that intercepts requests. So with Plexcel, if the client cannot do SPNEGO, the script can decide what to do which is usually to redirect the user to an SSL protected HTML login form where they then use Plexcel's API again to do a Kerberos 5 login. In either case you end up with a TGT for talking to other services (provided the service is permitted to delegate). WebAuth and Cosign are good solutions when you have disparate networks where some clients may only support cookies and nothing else. But for an IntrAnet environment where clients are logged into a domain 90% of the time, the performance and flexibility of direct SPNEGO / NTLMSSP is almost always going to be a better solution. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SSO
On Thu, Jul 17, 2008 at 11:01 AM, Sharad Desai <[EMAIL PROTECTED]> wrote: > Hello, > > Thanks for your responses. > >> You may want to search for SPNEGO and mod_auth_kerb. Windows IE and IIS >> have SPNEGO built in, and can use the Kerberos in Active Directory. >> Apache can use mod_auth_kerb that supports SPNEGO. With FireFox 2 on any > platform >> see the about:config and the network.negotiate-auth.trusted-uris option. > > I would have definitely considered this, but the group that I am working > with does not want to include AD in any solution. > > Also, (I'm not sure how familiar people are with Cosign) since Cosign > transforms Kerberos authentication to a cookie-based authentication which > the browsers can use, I was wondering if you have had any experience with > this. When trying to determine the right SSO solution for your web applications, it is important to realize that the mode of operation behind solutions that call themselves "SSO" varies tremendously so you really need to carefully state your requirements. For example, you mentioned WebAuth and CoSign. Both of these solutions are really targeted for highly heterogeneous environments like University networks where the only client requirement is that the browser support cookies. So it works on the IntrAnet, the IntErnet, on a hostile dormitory network, a kiosk at the airport, ...etc. But if you don't have those requirements these solutions do have quite a bit of overhead with all the redirecting and, more important, they do not give you true single-sign-on behavior. They're more like "double sign on" because you have to login to a central server and they get redirected back to the target site. Then you have "SSO" solutions like OpenID which are really more like "triple sign on" since you have to login to your workstation, then to the OpenID service and then put in the OpenID service you're using at the target site. This scenario is really only for the IntErnet where there is no chance of the client and service being members of the same domain. For a strictly IntrAnet environment the WWW-Authenticate: Negotiate or NTLMSSP protocols used by IIS, mod_auth_kerb, Plexcel, JCIFS and others are the only true *Single* Sign On solutions where the clients existing credentials are used to transparently authenticate without requiring the user to enter a password. These use either the original WWW-Authenticate: NTLM protocol (obsolete), raw NTLMSSP (rare), raw Kerberos 5 (rarer) or SPNEGO (very common - used to "negotiate" either NTLMSSP or Kerberos 5). Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb5_context in a threaded process
On Tue, Jul 8, 2008 at 11:25 AM, <[EMAIL PROTECTED]> wrote: > I need to initialize multiple krb5_context's in a multi-threaded > program > and each context *must* be initialized from a different config file. > > krb5_init_context() seems to read config from /etc/krb5.conf or the > file > pointed to by KRB5_CONFIG. Setting the environment variable will not > work since > "env"is for the process, not the thread. > > I was wondering if there is a better way to do this, other than > creating a mutex > to set/get the KRB5_CONFIG env variable before each krb5_init_context. Not really. What I did was add a krb5_config_set function to allow setting individual properties and then change the default krb5.conf location to an empty file. I believe Heimdal has such functions (although I don't know if the work was fully completed due to memory management issues). I don't know if MIT has such functions. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: help
On 6/15/08, kul gupta <[EMAIL PROTECTED]> wrote: > I am very new to kerborose and GSSAPI > I will highly appreciate for the guidance for the issues below- > I am bit confused about cyrus SASL and GSSAPI > > I have an authentication server (AS) which is kerborised > Client gets the TGT using -kinit > Now i need to use GSSAPI for authentication using GSSAPI > > 1) DO i need to have cyrus SASL also ?? or only kerborose will do?? Hi Ruchita, SASL and GSSAPI are two of several abstraction layers that are used to authenticate peers in different networking protocols. For example, an LDAP bind can use SASL which in turn can use GSSAPI whereas some HTTP clients can use GSSAPI directly. Why we need all of these layers I do not know but if you are using a protocol that uses SASL then yes you need SASL. If you are adding Kerberos authentication to your own networking protocol, then you do not need SASL and should probably just use GSSAPI directly. You could also skip the GSSAPI layer and use the Kerberos API directly but in practice there are a number of advantages to using GSSAPI. > 2) When i tried to run the example provided by SUN , i am getting following > errors- > gssapi_ext.h- No such file directory > gssapi-misc.h-No such file directory > > I also tried to search these files in my system(Red hat enterprise linux > 5.0),but these files are not present. RedHat ships with the MIT distribution of Kerberos. Install the kerberos-devel package and adjust the source code of your examples to use those header files. Or download the MIT source package and try the examples shipped with it with your RH provided system libraries. The later would probably be easier since those examples are designed to build with MIT libraries shipped with RH. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Password Salting Methods
On 6/2/08, Ken Raeburn <[EMAIL PROTECTED]> wrote: > On May 29, 2008, at 22:22, Michael B Allen wrote: > > > Is there a reference anywhere that outlines the different password > > salting methods used by different KDCs? > > > > There are RFCs 3961, 3962, and 4757, which outline how salt strings are > incorporated in the string-to-key conversion function for each cryptosystem. > RC4 ignores it, the others actually use it. > > How the salt string is determined is separate. > > According to RFC 4120, the default salt string is generated by joining the > realm and principal components without separators. If another string is to > be used, it must be indicated by some sort of preauth data like ETYPE-INFO2. > > The MIT KDC has support for some specific variations on salt strings, such > as using only the realm, only the principal name without the realm, "v4" > (i.e., no salt string at all, or rather an empty string), and "special" (a > string stored in the principal record in the database with the key). > > Using the principal name as a salt string makes it more difficult for an > attacker to precompute a dictionary of keys derived from a dictionary of > pass phrases. Instead of generating a single complete dictionary, the > attacker must pick a principal name (more to the point, a specific salt > string) to use in the dictionary generation. Or, the attacker could > multiply the pass phrase dictionary size by a set of principal names (salt > strings) to be attacked, which increases the work to be done by that > multiplier. > > Someday I'd like to see us have a flag in the database to indicate that > random salt strings should be generated at every password change. Then even > if a user keeps picking passwords that are in the attacker's dictionary, a > dictionary built based on one salt string will be useless as soon as the > password is changed. It probably would help to make them long, with > comparable random bits to the key size itself, rather than a set of short > alphanumeric strings as usernames often are. Then the distribution of > password-generated keys, over a large set of users and password changes, is > spread out over the entire key space. Someday > > Anyways, the enctype specification for the MIT KDC also indicates the salt > type to use for each, when creating principal entries or changing passwords. > > > > AFAICT AD w/ RC4 doesn't actually use a salt. Heimdal seems to just > > use the realm and principal name concatenated together without any > > separators. > > > > Right, that's the RC4 behavior, and the default salt as specified in the > protocol. > > > > What does MIT do? > > > > As above... > > > > What does Windows 2008 w/ AES use? > > Windows 2000? > > > > I can't tell you for sure offhand, but I would assume it probably either > uses the default per RFC 4120, or sends ETYPE-INFO(2) to indicate no salt > string is used. > > > > Do the salt values change depending on the enctype? > > > > The default is protocol-wide. However, the database could store different > salt strings for different encryption types. > > I'd have to think a bit to figure out if it's valid for the database to > have different salts for a single encryption type, with the KDC randomly > choosing between them. I don't know if that would break any interesting > assumptions that client software might reasonably make. > > > > I'm interested in knowing to what degree salts can be predicted given > > only the information a client preparing to issue an AS-REQ would have. > > > > Obviously you can guess that it'll use the default... You could also cache > the value from the previous time. Excellent information Ken. This will help a lot. Thanks, Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Password Salting Methods
Hi, Is there a reference anywhere that outlines the different password salting methods used by different KDCs? AFAICT AD w/ RC4 doesn't actually use a salt. Heimdal seems to just use the realm and principal name concatenated together without any separators. What does MIT do? What does Windows 2008 w/ AES use? Windows 2000? Do the salt values change depending on the enctype? I'm interested in knowing to what degree salts can be predicted given only the information a client preparing to issue an AS-REQ would have. Ultimately I'm trying to reduce ETYPE_INFO(2) discovery to improve performance and get rid of annoying Windows "preauthentication failed" event log errors. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Help required in using kerberos in our project
On Thu, May 15, 2008 at 2:11 AM, Anshuman Hazarika <[EMAIL PROTECTED]> wrote: > Hi , > > We are developing a product called as Zeus. In this > product we need our users to be authorised using > kerberos. > > We would like to know how to proceed with the > development of this module. > > We have the user information, like the user name and > password, stored in ldap. > > What we understand as of now is that we need to > download and install the mit kerberos server. After > that do we have to develop a kerberos client which > talks to the kerberos server? If so how do we go about > it?Are there APIs Available? Look into something called "GSSAPI". It is a general purpose API for exchanging authentication tokens of different types (including Kerberos) in an application specific way. There are GSSAPI libraries for Java (JGSS) and for C (shipped with MIT and Heimdal distributions). On Windows you have SSPI which is mostly compatible with GSSAPI (SSPI tokens can be consumed by GSSAPI and GSSAPI tokens can be consumed by SSPI). > Can the utilities like kinit be used to develop the > client which would take the username and password to > be authorized using kerberos. Kerberos clients usually already have a credential cache infrastructure. Kinit is just one program that can populate your credential cache with a Keberos ticket given a username and password. Windows clients get a ticket and put it in a kernel based credential cache when you login the first time (e.g. using Ctrl-Alt-Del). Most Kerberos client and server programs use entirely GSSAPI to handle authentication. The KDC (MIT, Heimdal, Active Directory, ...) should already be setup and running in the target environment. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: PAC missing from service tickets why?
On 4/24/08, Douglas E. Engert <[EMAIL PROTECTED]> wrote: > > Michael B Allen wrote: > > > Hi All, > > > > Sorry for the MS specific question. > > > > Regarding the Privilege Attribute Certificate in the > > authorization-data field, someone using my SPNEGO HTTP server product > > is getting an error that indicates no PAC is present in the service > > ticket supplied by the client. The server is Windows 2003 Server and > > the client is Vista SP1. If they try a non-Vista client, SSO works > > fine. > > > > Does anyone know of a reason why the PAC would be left out of the > > service ticket? > > > > > > Yes. If the userAccountControl flag NO_AUTH_REQUIRED is set on the service > account, the PAC will not be added to the service tickets for that service. > See http://support.microsoft.com/kb/832572 > > This was added to keep the size of a ticket down for services that did not > use the PAC, and had trouble with large tickets. (With out the PAC tickets > are about 240 bytes. With the large PAC, then can be as large as 12K. Hi Douglas, Well I thought for sure that would be the problem. But the user claims the userAccountControl value is 590336 which does not include NO_AUTH_DATA_REQUIRED (0x200). What happens if the token is larger than 12K? Anyone else have any ideas? Right now I'm modifying my code to get authorization data from LDAP if the PAC isn't present but obviously that's not an ideal solution as it will significantly slow things down. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
PAC missing from service tickets why?
Hi All, Sorry for the MS specific question. Regarding the Privilege Attribute Certificate in the authorization-data field, someone using my SPNEGO HTTP server product is getting an error that indicates no PAC is present in the service ticket supplied by the client. The server is Windows 2003 Server and the client is Vista SP1. If they try a non-Vista client, SSO works fine. Does anyone know of a reason why the PAC would be left out of the service ticket? Is there some new security policy that I don't know about? Any help would be appreciated, Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [SOLVED] Clock skew too great / System vs Hardware clock problem?
On Sat, Apr 19, 2008 at 6:50 PM, Markus Moeller <[EMAIL PROTECTED]> wrote: > Michael, > > what does the from/till timestamp in the AS_REQ say ? It says the right thing. Turns out the user didn't correctly check the time on the AD server. If you just do: C:\>time It doesn't report AM vs PM. Use the following to get AM vs PM: C:\>time /T The time on the Windows server was set to 3 AM and not 3 PM. Thanks, Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Clock skew too great / System vs Hardware clock problem?
I'm trying to diagnose a "Clock skew too great" error between a CentOS 5.1 client and Windows 2003 R2 ADS. If we date 'date' on the Linux the time is within a few seconds of the clock on the Windows server. The Linux machine's /etc/localtime is set to PST8PDT. The AD server is set to Pacific time. So now what? Could it be that the hardware clock and system clock are not in sync? >From experience it doesn't matter if the hardware clock is UTC or not. I'm stumped. Any ideas? Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion
On 3/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Note that accepting raw tokens is not terribly hard considering SPNEGO > > is largely a wrapper for the raw tokens. > > In our situation the Microsoft SSPI has decided that since there are > NTLM > credentials available due to an interactive logon to the same machine > that happens to run our application it's going to send the NTLM > credentials > instead of using the Kerberos credentials which are also available. > This > is due to special case code in the SSPI which prefers NTLM over > Kerberos > in this situation. That problem doesn't really have anything to do with SPNEGO. The SSPI layer knows nothing about interactive logons. The problem is that some application has acquired and inserted an NTLM credential into the credential cache so naturally the InitializeSecurityContext function as called by IE is going to pick that. That may not be optimal but it really has nothing to do with SPNEGO. The behavior you want would require that IE specify that it wants the SPNEGO mechanism and not the NTLM mechanism (not sure if SSPI supports the specification of a mechanism like GSSAPI does - it may simply infer the mechanism from the credential). > Now if they actually implemented SPNEGO as > required by > the RFC we would be able to respond with accept_incomplete and request > that the Kerberos token be used. I wouldn't be super confident that that would actually work. Again, just because you see something in an RFC doesn't mean that it actually works like that in practice. Our product provides a logon routine that allows authenticating clients using a traditional username+password method. That handles all of the "client will not or cannot do kerberos" scenarios and not just the one NTLM case. Note that NTLM doesn't support delegation so if I remember your original post correctly, implementing NTLM with pass-through authentication would not help your particular scenario. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion
On 3/18/08, Todd Stecher <[EMAIL PROTECTED]> wrote: > My reading of the RFC is that it is truly "informational," describing > how clients and servers use SPNEGO + HTTP, but not specifying every > possible HTTP auth scheme. Chances are the answer you got about raw > NTLM being "OK" was passed through various layers of Microsoft from > Larry Zhu, the author of the RFC itself, and based on not on > "correctness" but rather on the behavior of millions of deployed > clients and servers. Even if you could get MS to change the behavior > to your interpretation of the RFC, its not going to help much until > every machine out there is updated. I would hope that they do NOT change the existing behavior. I consider accepting "raw" NTLM and Kerberos tokens to be a feature. In fact, SPNEGO is largely dead weight - I don't recall seeing it ever "negotiate" much of anything. It's just one of those things that sounded nice in theory but in practice it didn't really help anyone. But MS clients send SPNEGO tokens so we need to accept them. Note that accepting raw tokens is not terribly hard considering SPNEGO is largely a wrapper for the raw tokens. It's an extra condition in your code. Or just use a GSSAPI implementation that supports SPNEGO and you're done. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion
On 3/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Mar 18, 12:59 am, "Michael B Allen" <[EMAIL PROTECTED]> wrote: > > If the HTTP server returns "WWW-Authenticate: NTLM" then the client > > must use NTLMSSP tokens. If it returns "WWW-Authenticate: Negotiate" > > then the tokens must be SPNEGO. If it returns both, then the client > > can pick. > > > Yep ... that's pretty much how I understand things. In our case we > are > only returning "WWW-Authenticate: Negotiate". > > > > Otherwise, you need to explain the point of failure in more detail. > > > The IE client is responding to "WWW-Authenticate: Negotiate" with > a raw NTLM instead of SPNEGO. Well I just looked at some of my captures and I can see that raw NTLMSSP tokens can be sent in response to "WWW-Authenticate: Negotiate". And I now recall that raw Kerberos tokens can be used as well. > > If you're not sure then provide an HTTP client / server call sequence > > > We're sure ... it's all been check / doubled checked using pack > sniffers, Well I'm glad you're sure but I'm not clear on what the point of failure is so if you want my input you'll have to explain the exact exchange. If you're seeing an XP client send a raw NTLM token in response to sending it "WWW-Authenticate: Negotiate" then I refer you to my original response. > etc. Microsoft has also confirmed it and looked at their code. They > say that it's intentional to return a raw NTLM instead of SPNEGO > regardless of the availability of Kerberos in some situations when > responding to "WWW-Authenticate: Negotiate". > > > the point of failure. > > The real problem is that Microsoft admits that this is intentionally > and claims that it is RFC4559 compliant. I'm having great difficulty > in getting them to understand that RFC4559 * requires * that SPNEGO > be used. I'm open to suggestions. >From glancing at RFC 4559 it indeed does not seem to include any mention that raw NTLM and Kerberos tokens are accepted. But I learned a long time ago that RFCs are not the law. What you see on the wire is the law. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion
On 3/17/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Mar 17, 9:12 pm, "Michael B Allen" <[EMAIL PROTECTED]> wrote: > > The problem is that the client will not or cannot initiate Kerberos. > > > Nice try, however no. The client has no problems using Kerberos. > There are credentials in the cache for user. There's no problem > fetching credentials for the webserver. The problem has specifically > been traced by Microsoft to a bit of code in the Negotiate SSPI > which causes a raw NTLM to be returned instead of a SPNEGO > in some situations even though Kerberos is available / working. If the HTTP server returns "WWW-Authenticate: NTLM" then the client must use NTLMSSP tokens. If it returns "WWW-Authenticate: Negotiate" then the tokens must be SPNEGO. If it returns both, then the client can pick. Otherwise, you need to explain the point of failure in more detail. Is it gss_accept_sec_context that is returning a token you didn't expect, or InitializeSecurityContext, or what? If you're not sure then provide an HTTP client / server call sequence w/ headers that illustrates the point of failure. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion
On 3/17/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Feel free to point me to the right group if I'm in the wrong place, > I wasn't quite sure of the best group for a HTTP protocol question. > > We have a web application which needs to log into a backend data > service as the user who accessed our application. Now the standards > compliant way to accomplish this would seem to be to return a 401 > WWW-Authenticate: Negotiate which should result in the browser using > SPNEGO to send the server a list of the supported authentication > mechanisms along with the optimistic mechanism token (as per RFC4559 > and RFC4178). As long as one of the listed mechanisms is Kerberos > we should be able to use SPNEGO to get the Kerberos token which will > allow us to log into our data service. > > This appears to work for the most part (tested with Firefox and IE), > however in some cases our server receives a NTLM token instead of a > SPNEGO in response to the 401. This problem occurs with both Firefox > and IE. A packet trace shows Negotiate was the only WWW-Authenticate > header we supplied when we responded. The configuration is correct > and Kerberos credentials are available. Microsoft has looked into > the issue and has stated that the Microsoft SSPI correctly implements > RFC4559. Specifically they've stated that in some cases the SSPI will > return a NTLM token instead of a SPNEGO token causing the browser to > return Authorization: Negotiate with a non-SPNEGO token and that this > behavior complies with RFC4559. > > Now my understanding of RFC4559 is that SPNEGO must always be used by > the client when responding. The NTLM is allowed to be * inside * of > the > SPNEGO. > > Anyone care to clear up the confusion, or suggest how to go about > resolving > the issue? Hi John, The problem is that the client will not or cannot initiate Kerberos. There could be many reasons for this: 1) The client cannot obtain a Kerberos ticket for the desired service. There can be many reasons for this too: 1a) If a MS client is not "joined" to a domain it cannot participate in Kebreros authentication and thus the client has no choice but to fall-back to using NTLM. 1b) A temporary network failure has prevented the client from acquiring the necessary ticket and thus the client has no choice but to fall-back to using NTLM. 1c) The XP credential cache bug [1] is preventing the client from renewing tickets causing the client to fall-back to NTLM. 2) The browser must be configured to trust the target server. In IE you must add the target server or it's domain under Tools > Internet Options > Security > IntrAnet Zone. 3) In some browsers automatic authentication must be enabled. For example, in IE you must turn on Tools > Internet Options > Advanced > Enabled Integrated Windows Authentication. 4) The user entered and saved credentials into a Network Password Dialog which preempts the client to initiate NTLM rather than Kerberos. 5) There is a problem with the service principal name on the service account preventing the client from initiating Kerbeors authentication and thus the client has no choice but to fall-back to using NTLM. I recommend using wfetch.exe (available on MS's website) to narrow down where the problem is. You can also look at our product manual at http://www.ioplex.com/support.html. In particular see "Issue 3" and "Issue 5" in the "Possible Issues" section. That document details all of the conditions described here and much more. Even though our code is completely different from what you're using the condition is the same (described as the "GSS_S_BAD_MECH" error in our document). Mike PS: Also note that the HTTP service account must be set to permit delegation. Otherwise, even if you get the client to do Kerberos you won't get the delegated ticket necessary to impersonate the user when initiating auth with the next tier. [1] http://support.microsoft.com/kb/885887 http://support.microsoft.com/kb/906524/en-us -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Problem configuring kerberos delegation on a windows 2003 domain
On 2/29/08, Lima Valdes Emil <[EMAIL PROTECTED]> wrote: > Kerberos trace: > 500.652> Kerb-Warn: KerbGetTgsTicket failed to unpack KDC reply: 0x3c > HTTP a_service.smnyl.com.mx Hi Emil, All of your diagnostics are very Windows specific which isn't going to translate well here. You might try to get a capture and generally adjust your terminology into "failed to get a TGT", "the SPN is", "service ticket this", "credential that", ... Is the "HTTP a_service.smnyl.com.mx" supposed to be an SPN? Perhaps that should be "HTTP/a_service.smnyl.com.mx"? Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030B: LdapErr:DSID-0C09043E
On 2/27/08, Ramesh Rao <[EMAIL PROTECTED]> wrote: > > Hi , > > > > I have a setup as follows: > > 1. Win2003 AD Server > > 2. Win2003 Client connected to the AD Domain > > 3. Now i have krb5.ini, Java Program and JASS conf files (Please > > find attachment for these files) > > 4. When i try to run > > java -Djava.security.auth.login.config=searchWithAuth.conf - > > Djava.security.krb5.conf=krb5.ini -Dsun.security.krb5.debug=true > > SearchWithAuth > > > > Iam getting the following: > > D:\Kerberostools>java - > > Djava.security.auth.login.config=searchWithAuth.conf -Dja > > va.security.krb5.conf=krb5.ini -Dsun.security.krb5.debug=true > > SearchWithAuth > > Kerberos username [Ramesh.rao]: Ramesh.rao > > Kerberos password for Ramesh.rao: Password12 > > >>> EType: sun.security.krb5.internal.crypto.DesCbcMd5EType Are you sure the account for 'Ramesh.rao' in AD is using DES? User accounts are RC4 by default unless the "This account uses DES encryption" flag is set. Mike > > javax.naming.AuthenticationException: [LDAP: error code 49 - > > 8009030B: LdapErr: > > DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece ] > > at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:2988) > > at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java: > > 2934) > > at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java: > > 2735) > > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2649) > > at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:290) > > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL > > (LdapCtxFactory.java:175) -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos.app AD UPN & SAM authentication issue
On 10/22/07, Ben W Young <[EMAIL PROTECTED]> wrote: > Thanks Guy's for helping me think through this. We have very large complex > AD environment and to suggest changes like turning on "translation" between > the UPN and the SAM would be like trying to get blood out of a stone. Hi Ben, That was not the conclusion. My understanding now is that Kerberos.app could be modified to use the MS specific "enterprise principal" when requesting the ticket rather than the regular "principal". Meaning there's a spot in the Kerberos.app code where you would simply need to change the principal type value from 1 to 10. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos.app AD UPN & SAM authentication issue
On 10/5/07, Markus Moeller <[EMAIL PROTECTED]> wrote: > I think you have to differentiate between the different principal types. > > MS can use the enterprise principal type 10 which is matched against the > UPN. Also when using the UPN with the canonicalisation flag set AD returns > the Samaccountname. Hi Markus, Interesting. To see for my self exactly what was happening in the XP workstation login w/ userPrincipalName scenario I described, I took a capture and indeed I see: AS-REQ: [EMAIL PROTECTED] type 10 AS-REP: [EMAIL PROTECTED] type 1 So it seems canonicalization is on and working in my test AD environment. There's no "translation" going on as I suspected previously. I didn't think I changed any settings so I assume canonicalization is on by default in AD. Now we could use GSS_C_NT_ENTERPRISE_PRINCIPAL for gss_import_name. I see Heimdal's gss_import_name doesn't handle it yet (although it does at the krb5 level). Thanks, Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos.app AD UPN & SAM authentication issue
On 10/4/07, Russ Allbery <[EMAIL PROTECTED]> wrote: > "Michael B Allen" <[EMAIL PROTECTED]> writes: > > > Active Directory does not use the userPrincipalName attribute to do > > Kerberos authentication. It uses [EMAIL PROTECTED] > > I just tested against our Active Directory with an account that had both > userPrincipalName and sAMAccountName set to different values and was able > to authenticate using either of the two names via kinit from a Debian > system. Either returned valid tickets for the principal name that I used, > and both had the same password and hence were using the same Active > Directory record. Hey Russ, Ok, I messed this up a little. Windows clients always use [EMAIL PROTECTED] to intiate Kerberos authentication but, you're right too, AD will accept the userPrincipalName. To demonstrate this, try logging into a Windows workstation joined to an AD domain using the userPrincipalName. Then run kerbtray and look at the Client Principal Name. You'll see the [EMAIL PROTECTED] form. The only way it could get a TGT like that is if it translated the userPrincipalName to [EMAIL PROTECTED] before it requested the it. So my conclusion was wrong, Kerberos.app should work for Ben. Not sure why it doesn't. Note that this creates issues for apps that use the client principal name as an identity used to search for stuff or hang data on in a DB (same thing) because now there are two possible identities. This is why all of our products normalize on the sAMAccountName. Otherwise, with our MediaWiki plugin for example, the same user could end up with two accounts. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos.app AD UPN & SAM authentication issue
On 10/4/07, Ben W Young <[EMAIL PROTECTED]> wrote: > Hi, > > Has anyone come across an issue where you cannot authenticate using the > Kerberos.app (or kinit) with an AD account with a different name for the UPN > and SAM? The SAM will authenticate but not the UPN? If the UPN and the SAM > are the same it authenticates. Hope I explained my self ok...? > > E.g. > Trying to authenticate as "bob.jackson" > Account: > UPN:[EMAIL PROTECTED] > SAM:bjackson > Doesn't work > > Trying to authenticate as "bjackson" > UPN: [EMAIL PROTECTED] > SAM: bjackson > works! Hi Ben, Active Directory does not use the userPrincipalName attribute to do Kerberos authentication. It uses [EMAIL PROTECTED] The Windows credential dialog will accept the userPrincipalName but it queries the directory, retrieves the sAMAccountName and uses that name to initiate Kerberos authentication instead. > If I change the SAM account to the UPN bob.jackson it works? Yes. If the userPrincipalName is the same as the sAMAccountName then of course it will work. AD doesn't really use the userPrincipalName attribute for much of anything that I'm aware of. I asked around about this once and got some cryptic answers. So it is used but not for initiating Kerberos authentication. My impression is that it's just some kind of indirection mechanism. > Also, why cant I authenticate with the true UPN name: [EMAIL PROTECTED] > > Is it something I have to change in the edu.mit.kerberos file? See below > example? No and no. There's nothing you can do. Kerberos.app would have to be modified to detect AD and query for the sAMAccountName and then build the required client principal name using it (which is problematic in itself because it would need a "machine account" of some kind to be able to search anything beyond the RootDSE). Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Active Directory LDAP SSH
On 9/4/07, Roman S <[EMAIL PROTECTED]> wrote: > > Hey guys! > > I've configured a Microsoft Active Directory with LDAP and Kerberos, and some > Linux (Redhat) clients who authenticate to it. > I'm able to get some tickets for the users who are in the Active Directory, > but SSH behaves a bit strange. > > I can always ssh to the same machine again. > Like > #foo: ssh foo > > but I can't ssh to any other computers. I always get a Permission denied. > I've only enabled gssapi authentication, all others are disabled. > Debug output of ssh didn't get me any further. Hi Roman, Did you create the host principal and keytab for the target server? Also, you'll need a .k5login file in the home directory of the target: $ cat ~/.k5login [EMAIL PROTECTED] Google for info about the above and you should find a tutorial I would think. Mike > At the moment users are basicly managed over NIS, only a few test users are > in LDAP, so they don't have home directories. I don't know if this could > cause the trouble. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Creating SPNEGO tokens
On 7/1/07, Markus Moeller <[EMAIL PROTECTED]> wrote:
> I think I found the reason the string has to be "{ 1 3 6 1 5 5 2 }".
> Wouldn't it make sense to have it already defined in a gssapi header file
> like Heimdal has as gss_mech_spnego ?
Actually it is in gssapi/gssapi_spnego.h:
extern gss_OID GSS_SPNEGO_MECHANISM;
#define gss_mech_spnego GSS_SPNEGO_MECHANISM
But if you don't want to include an implementation specific file you
can just define it yourself like:
static gss_OID_desc _gss_mech_spnego = {6, (void *)"\x2b\x06\x01\x05\x05\x02"};
gss_OID _GSS_MECH_SPNEGO = &_gss_mech_spnego;
Mike
>
> Markus
>
> "Markus Moeller" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > But the input to gss_init_sec_context is a gss_OID structure. How do I
> > build the structure ? If I use gss_str_to_oid I get an error "Invalid
> > argument"
> >
> > Thanks
> > Markus
> >
> > "Michael B Allen" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >> On 6/30/07, Markus Moeller <[EMAIL PROTECTED]> wrote:
> >>> Which mech OID do I need to use in gss_init_sec_context to get a SPNEGO
> >>> token ? I looked in the header files of 1.6.1 but it is not defined
> >>> there.
> >>
> >> Hi Markus,
> >>
> >> The OID for SPNEGO is 1.3.6.1.5.5.2.
> >>
> >> Mike
> >>
> >> 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
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Creating SPNEGO tokens
On 6/30/07, Markus Moeller <[EMAIL PROTECTED]> wrote: > Which mech OID do I need to use in gss_init_sec_context to get a SPNEGO > token ? I looked in the header files of 1.6.1 but it is not defined there. Hi Markus, The OID for SPNEGO is 1.3.6.1.5.5.2. Mike Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: AW: AW: AW: Some Users get Basic Auth?
On Thu, 14 Jun 2007 15:19:59 +0200 "Djihangiroff, Matthias (KC-DD)" <[EMAIL PROTECTED]> wrote: > Hello, > > We'have just created a new domain Account and voila, all is running fine. > So somekind of settings in the userprofile are incorrect, so the auth box > popped up. > > Now we have another problem. > > SOME users are getting this basic auth box somtimes. IE is running in NTLM > mode.. > If you close the IE, and open it again, with the same URL, all is running > fine. > > What the hell is wrong with this IE thing :-( Hi Matthias, Honestly the best way to determine what's going on is to get a packet capture and do a network analysis. The problem with that is that clients cache both positive and negative Kerberos ticket request results so you basically have to reboot the client, start the capture, launch IE, try the page and if it fails restart the browser and if it then succeeds stop the capture. If it doesn't fail or if it doesn't succeed after failing you won't have to two conditions you need to compare and you have no choice but to reboot the client and repeat. But if you do get a capture like that I'll look at it. Can't guarantee I'll find anything but I'm always interested in these sorts of failure conditions. There is a decription of getting a capture with netcap.exe in the appendix of that document I pointed you to before. Also, you might try to get this patch: http://support.microsoft.com/kb/885887 It does sound remotely like what you're seeing and some people have had success with it when experiencing unreliable behavior like you're describing. Mike > -Ursprüngliche Nachricht- > Von: Michael B Allen [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 13. Juni 2007 08:57 > An: Djihangiroff, Matthias (KC-DD) > Cc: Todd Stecher; kerberos@mit.edu > Betreff: Re: AW: AW: Some Users get Basic Auth? > > On Wed, 13 Jun 2007 08:25:51 +0200 > "Djihangiroff, Matthias (KC-DD)" <[EMAIL PROTECTED]> wrote: > > > Thanks. > > > > Than i dont know why IE is switching to NTLM. > > It doesnt matter if i type http://someserver or with our domain > > http://someserver.konzern.intern (thats although the registerd machine > > account in the domain). > > The auth box pop ups every time. > > > > I think, thats somekind of defect windows profile. > > If i login with MY windows account, all is running perfect. If i login > > with a user account, they get the auth box. (Both on the same machine, > > the same domain) > > > > I'm informing our Windows admins and hope, they can make some brand > > new windows account for me for testing purposes in that domain. > > Matthias, > > On this website: > > http://www.ioplex.com/support.html > > You will find a document called the Plexcel Operator's Manual. The document > is mostly about our SSO product but of course the protocol is the same so the > "Possible Issues" section has information about troubleshooting this sort of > thing. In particular look at Issue 3 and Issue 5. > > Mike > > > > > > > Von: Todd Stecher [mailto:[EMAIL PROTECTED] > > Gesendet: Mittwoch, 13. Juni 2007 08:18 > > An: Djihangiroff, Matthias (KC-DD) > > Cc: Michael B Allen; kerberos@mit.edu > > Betreff: Re: AW: Some Users get Basic Auth? > > > > > > > > On Jun 12, 2007, at 11:04 PM, Djihangiroff, Matthias (KC-DD) wrote: > > > > > > I've checked the browser settings, Integrated Windows Auth is > > checked. > > > > > > > > > > Where can i configer the browser, that it use only Kerberos? > > > > I didnt find any option. > > > > > > You can't. A lot of it depends on the URL you present to IE, which > > will in turn dictate what protocol is chosen under SPNEGO. > > > > When you type "http://someserver";, then IE will present the kerberos > > package on the client with the service principal name (SPN) of > > http/someserver. For kerberos to work, you need a service ticket > > matching that SPN. This will only be possible if the web server is > > properly registered with a machine account in your client's domain, or > > potentially another domain in the forest (assuming you're using AD). > > > > In some cases, IE will do a reverse lookup and expand the someserver > > to http/someserver.domain.com, but the SPN lookup rule still applies. > > > > If kerberos can't find the SPN (for example if the target server isn't > >
Re: AW: AW: Some Users get Basic Auth?
On Wed, 13 Jun 2007 08:25:51 +0200 "Djihangiroff, Matthias (KC-DD)" <[EMAIL PROTECTED]> wrote: > Thanks. > > Than i dont know why IE is switching to NTLM. > It doesnt matter if i type http://someserver or with our domain > http://someserver.konzern.intern (thats although the registerd machine > account in the domain). > The auth box pop ups every time. > > I think, thats somekind of defect windows profile. > If i login with MY windows account, all is running perfect. If i login > with a user account, they get the auth box. (Both on the same machine, > the same domain) > > I'm informing our Windows admins and hope, they can make some brand new > windows account for me for testing purposes in that domain. Matthias, On this website: http://www.ioplex.com/support.html You will find a document called the Plexcel Operator's Manual. The document is mostly about our SSO product but of course the protocol is the same so the "Possible Issues" section has information about troubleshooting this sort of thing. In particular look at Issue 3 and Issue 5. Mike > > > Von: Todd Stecher [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 13. Juni 2007 08:18 > An: Djihangiroff, Matthias (KC-DD) > Cc: Michael B Allen; kerberos@mit.edu > Betreff: Re: AW: Some Users get Basic Auth? > > > > On Jun 12, 2007, at 11:04 PM, Djihangiroff, Matthias (KC-DD) wrote: > > > I've checked the browser settings, Integrated Windows Auth is > checked. > > > > > Where can i configer the browser, that it use only Kerberos? > > I didnt find any option. > > > You can't. A lot of it depends on the URL you present to IE, which will > in turn dictate what protocol is chosen under SPNEGO. > > When you type "http://someserver";, then IE will present the kerberos > package on the client with the service principal name (SPN) of > http/someserver. For kerberos to work, you need a service ticket > matching that SPN. This will only be possible if the web server is > properly registered with a machine account in your client's domain, or > potentially another domain in the forest (assuming you're using AD). > > In some cases, IE will do a reverse lookup and expand the someserver to > http/someserver.domain.com, but the SPN lookup rule still applies. > > If kerberos can't find the SPN (for example if the target server isn't > registered in a trusted domain, or the client's KDC can't be reached > over the presently connected network), it will drop back to NTLM > (wrapped in SPNEGO tokens). There's really no easy way to guarantee > Kerberos, and, in fact, NTLM is frequently the protocol chosen for http > auth. > > We tried, in the old days to get rid of NTLM, but that's not possible > w/o service interruptions unless you can *always* get a service ticket > to the server. > > Todd > > persona service Verwaltungs AG & Co. KG > Freisenbergstra_e 31 _ 58513 L_denscheid > Tel.: (02351) 950-0 _ Fax: (02351) 950-222 > Sitz L_denscheid _ Registergericht Iserlohn, HRA Nr. 2930 > > pers_nlich haftende Gesellschafterin: persona service AG > Gartenstra_e 93 _ CH-4002 Basel > Handelsregister Basel, Nr. CH-270.3.012.836-8 > diese vertreten durch den Verwaltungsrat: > Dipl.-Ing. Werner M_ller (Pr_sident) und Dr. Sebastian Burckhardt > www.persona.de > -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Some Users get Basic Auth?
On Tue, 12 Jun 2007 10:10:15 +0200 "Djihangiroff, Matthias (KC-DD)" <[EMAIL PROTECTED]> wrote: > Hi, i have a huge problem. > > Some of our Users get randomly the Basic Auth Box, some get it ALWAYS. > > I sniffed the HTTP Trafic: > > So the interesting line is "Authorization: Negotiate > TlRMTVNTUAABB4IIogAFASgKDw==" > > That doesnt look like a Kerberos Service Ticket? Is that NTLM? 0: 4e 54 4c 4d 53 53 50 00 01 00 00 00 07 82 08 a2 |NTLMSSP.| 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 00020: 05 01 28 0a 00 00 00 0f |..(.| This is raw NTLMSSP. Check your browser settings. Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
IE 7 pops up Network Password Dialog on FIRST 401 Unauthorized
Hey, Has anyone noticed that IE 7 pops up that Network Password dialog with the first 401 Unauthorized request even if the server does not advertise NTLM? Other versions of IE will not pop up that dialog until the *second* 401 Unauthorized. That gives the server a chance to send 200 w/ an error page or a login page. Now you can't. So if you have a Kerberos site with fallback to a login form this annoying and confusing Network Password dialog pops up and you have to hit cancel five times to get in. Someone please tell me there's a registry setting to fix this. Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Website- Kerberos: The Network Authentication Protocol
Thomas, Your post is totally inappropriate. Please do not post this stuff here (or anywhere else for that matter). Mike Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Firefox Requests TGT Every Time it Authenticates?
Hi, Has anyone noticed that Firefox (1.5.0 on Linux x86 in my case at least) requests a TGT everytime it authenticates? Why doesn't it use the one it has in the ccache? It gets the HTTP service ticket from the ccache file just fine. Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos for authentication, php for authorization
On Fri, 8 Jun 2007 18:14:38 +0100 Simon Wilkinson <[EMAIL PROTECTED]> wrote: > Aside: If you're using a single, general purpose, keytab you almost > certainly _don't_ want the GSS_C_NO_CREDENTIAL behaviour - you want > to be sure that your ssh service will only accept 'host/' principals, > for example. Ahh, ok. But why is using GSS_C_NO_CREDENTIAL a problem exactly? If the key is good the key is good no? Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos for authentication, php for authorization
On Fri, 8 Jun 2007 09:00:09 +0100 Simon Wilkinson <[EMAIL PROTECTED]> wrote: > Ultimately, this means you may need to have a keytab containing > multiple different prinicpals for your service, and have > mod_auth_kerb accept any one of these principals. Unfortunately, the > code isn't there to do that in current mod_auth_kerb's. This seems odd to me. The krb5 lib should automatically seek out the right key by searching for the desired principal, enctype and kvno. I have tested this. The setup script for our product will generate a keytab with an entry for each SPN mapped to the Windows account. Then you can use any one of those hostnames and it works equally well. What is it that mod_auth_kerb is doing differently? Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos for authentication, php for authorization
On Thu, 7 Jun 2007 23:16:26 +1000 "Steve Webb" <[EMAIL PROTECTED]> wrote: > Hello, > > I have been requested to build a web app for my medium sized organization > that currently have Kerberos 5 running on the network. The webapp will > require non-technical users to be able to log on remotely through a web > browser (IE only is fine but there must not be any other client programs > involved) and then be given different privilidges within the app depending > on their role. > > Being a newbie to kerberos I have done some reading about possible > implementation techniques for Kerberos in web apps but have one question I > am hoping some of the gurus out there may be able to help with: > *Q. Can Kerberos be used to authenticate users and a php script then given > access to a users username in order to authorize privilidges??* > > >From my reading I believe that using the mod_auth_kerb module for Apache in > Negotiation mode may be the best bet for my needs but am hoping to confirm > whether or not a php script on the same apache server can gain access to the > users username in order to ascertain roles from a database, where I am quite > happy to duplicate usernames if need be. > > If this scenario is not possible, can anyone offer suggestions as to a > viable method to implement such a web application. Hi Steve, If you're using AD and your web server is Linux, there's a product that is specifically designed for this sort of thing. It's called Plexcel: http://www.ioplex.com/plexcel.html Plexcel will authenticate clients using Kerberos 5 / SPENGO / Single Sign-On (SSO) but users can also authenticate using explicit credentials (e.g. if they're not logged into the domain). You have access to all of the user's information within the script and you can check to see if they're in different Windows groups. You can set passwords, create accounts, whatever. You can find detailed API documentation here: http://www.ioplex.com/api/plexcel_new.html Also, it's free for up to 25 users. If you have any more questions feel free to contact our support email directly. Or you could use mod_auth_kerb to do the authentication and then use the PHP ldap API to check group membership but you'll find a few limitations in this solution. Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: authentication on windows xp thru kerberos
On Wed, 06 Jun 2007 15:58:38 +0200 "Luca Lauretta" <[EMAIL PROTECTED]> wrote: > Hi, i have a problem , i can't get to authenticate myself on windows XP thru > kerberos database, located on another pc using linux. > > what should i do? Hi Luca, What you should do is find a document that describes the scenario you're interested in [1][2]. Then, when you find that the result is not consistent with what the document says, you should look carefully at the error message and do an analysis of the problem. If you cannot decipher the error and the error is related to the Kerberos protocol, then you might post the exact error text here. Mike [1] http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx#EVCAC [2] http://www.h5l.se/manual/heimdal-0-7-branch/info/heimdal.html#Configuring-Windows-2000-to-use-a-Heimdal-KDC -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gssapi auth, and multihomed multinamed hosts
On Wed, 6 Jun 2007 19:36:38 +1000 Edward Irvine <[EMAIL PROTECTED]> wrote: > Hi Folks, > > I have a Solaris 10 server with two ip addresses: "fixed.example.com" > and "float.example.com". The latter is an IP address that the server > sometimes assumes as part of its role in a high-availability cluster. > > I have compiled my own openssh+gssapi version of sshd, and have got > ssh single-sign-on working fine (both windows secureCRT, a patched > version of Putty, and also the unix openssh clients) . So far so good. > > It is now time to get gssapi auth to working with the > "float.example.com" address. > > Can I expect to just add the keytab for "float.example.com" into /etc/ > krb5.keytab and expect everything to be OK? Hi Edward, I don't have first hand knowledge of this particular scenario but from what I know about GSSAPI it should work fine. GSSAPI works by name so provided the key on the KDC associated with the service principal matches the key in the keytab used by sshd then it should work. Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
