Re: Authentication Indicators and Cross Realm Trust

On Sun, 2022-10-09 at 17:38 -0400, Ken Hornstein via Kerberos wrote: > > On 9/30/22 16:06, Machin, Glenn Douglas via Kerberos wrote: > > > Can someone tell me if a TGT containing an authentication > > > indicator will work over to a service principal in another realm >

Re: Authentication Indicators and Cross Realm Trust

>On 9/30/22 16:06, Machin, Glenn Douglas via Kerberos wrote: >> Can someone tell me if a TGT containing an authentication indicator will >> work over to a service principal in another realm which has a cross realm >> trust relationship? > >Authentication indicators

Re: Authentication Indicators and Cross Realm Trust

On 9/30/22 16:06, Machin, Glenn Douglas via Kerberos wrote: Can someone tell me if a TGT containing an authentication indicator will work over to a service principal in another realm which has a cross realm trust relationship? Authentication indicators are currently only accepted within the

Authentication Indicators and Cross Realm Trust

Can someone tell me if a TGT containing an authentication indicator will work over to a service principal in another realm which has a cross realm trust relationship? Thanks, Glenn Kerberos mailing list Kerberos@mit.edu https

Re: Question about (no-)cross-realm trust

Thanks Greg for clarifying. Good to know that 'trust' is specific to MS AD. Actually the "1.2. Cross-Realm Operation " section in RFC 4120 was throwing me off. I also found & read the memo [RFC-5868] Problem Statement on the Cross-Realm Operation of

Re: Question about (no-)cross-realm trust

On 9/17/19 10:22 PM, Vipin Rathor wrote: > I am trying to develop an application which can talk to a kerberized > service running in a remote realm. I am aware that this would ideally > require having trust (one way or two way) between my current realm and > remote realm. Additionally, we want to a

Question about (no-)cross-realm trust

Hello Kerberos World! I am trying to develop an application which can talk to a kerberized service running in a remote realm. I am aware that this would ideally require having trust (one way or two way) between my current realm and remote realm. Additionally, we want to avoid having trust as a requ

Active Directory - Hortonworks MIT Kerberos cross realm trust establishment

We are trying to configure IWA for SAS Data Loader for Hadoop (DLH). SAS Servers are running under Active Directory domain and SSO is successfully configured. We need to configure DLH to talk to Hortonworks Hadoop MIT Kerberos using client generated tickets. That functionality is not working. So

Re: Cross-realm Trust Principals with LDAP

Hi Greg, Thanks for the suggestion – I had completely forgotten this would show up in the LDAP logs. After running that down, it turns out (surprise!) to be a case of user error. The search base for the VIASAT.IO principals was wildly different from the base for our subrealms. One of our eng

Re: Cross-realm Trust Principals with LDAP

On 01/22/2017 07:11 PM, Kemper, Stephan wrote: > Sorry for the spam, but after continuing to investigate, it looks like this > database shortcut only works for vertical trusts. A > krbtgt/a.viasat...@b.viasat.io principal only shows up in the realm it’s > created in. That definitely pushes me

Re: Cross-realm Trust Principals with LDAP

Sorry for the spam, but after continuing to investigate, it looks like this database shortcut only works for vertical trusts. A krbtgt/a.viasat...@b.viasat.io principal only shows up in the realm it’s created in. That definitely pushes me toward the “unintended/bug” end of the spectrum, becau

Cross-realm Trust Principals with LDAP

Hello again! Based on my previous question (“Cross-Realm Admins” from last month) we’re now using a model with separate admin principals per realm, and a large keyring of keytab files. This seems to be working *mostly* fine. Where we run into issues is with creating the cross-realm trusts, spe

Re: Cross Realm Trust with AD - PROCESS_TGS Error

Please disregard this. It was a password mismatch after all, in some way, shape, or form. The password used for the trust principal was a strong password with many special characters, and despite recreating the principal numerous times with the password checked and rechecked on each side, it

Re: Cross Realm Trust with AD - PROCESS_TGS Error

And one more potentially useful piece of information that may suggest the krbtgt/linux.example@windows.example.com principal doesn't exist: [selble@NW-8504LM ~]$ kinit krbtgt/linux.example@windows.example.com krbtgt/linux.example@windows.example.com's Password: kinit: krb5_get_init_c

Cross Realm Trust with AD - PROCESS_TGS Error

Hi, I'm running into a situation where I have setup a one-way trust with a MIT Kerberos realm (LINUX.EXAMPLE.COM) trusting a AD realm (WINDOWS.EXAMPLE.COM). The krbtgt/linux.example@windows.example.com principal exists in both realms, and I *believe* that the password for the principal is

Re: cross-realm trust MIT and Windows 2008 - Authentication issues

On 8/2/2012 12:08 PM, c.ra...@t-online.de wrote: > Greethings, > > I have the following setup: > > -A MIT-Kerberos Realm MITREALM containing user principals > (user@MITREALM [1]) > -A Windows 2008 Active Directory ADS.NET which is configured on DC > adsdc01. > -A Windows 2008 Domain m

cross-realm trust MIT and Windows 2008 - Authentication issues

Greethings, I have the following setup: -A MIT-Kerberos Realm MITREALM containing user principals (user@MITREALM [1]) -A Windows 2008 Active Directory ADS.NET which is configured on DC adsdc01. -A Windows 2008 Domain member admember within ADS.NET domain. -There is a crossrealm

cross realm trust

Hi all, I am trying to setup a cross realm authentication between microsoft and mit kerberos running on rhel. Mit kerberos realm is going to trust to ms realm. Both kdc'a are running fine in their own realms. We have set up principals on both kdc's. krbtgt/mit.realm@ms.realm A windows client t

Re: some cross-realm trust questions

I have been able to ssh from a Windows host (using Centrify PuTTY) to a FreeBSD host using a cross-realm trust between a w2k domain and a Heimdal realm. However, I had to manually configure the Windows host for this to work: "ksetup /addkdc MY.UNIX.REALM server1 server2". Do you know

Re: some cross-realm trust questions

Mark Pr?hl wrote: [dd] > > And BTW how do I figure out what enctypes AD is configured to provide? > > Is there anything like "kadmin get" for AD? > > > In Windows 2008 R2 the encryption types of inter-realm keys can > be configured with ksetup.exe. Cross realm trusts to kerberos > realms use rc4

Re: some cross-realm trust questions

On 12/28/2010 06:02 PM, Victor Sudakov wrote: > Russ Allbery wrote: > > [dd] > >>> But it still escapes me how on earth I will end up with >>> krbtgt/unix.re...@windows.realm andkrbtgt/windows.re...@unix.realm >>> having the same key. There is nothing in the above articles about >>> exporting and

Re: some cross-realm trust questions

Russ Allbery wrote: > > I am just curious. What Windows client programs and Unix server programs > > (or vice versa) must you use? How do you use this trust? > We allow all Active Directory users at Stanford to log on either in the AD > realm or in the university Heimdal realm, and try to set up a

Re: some cross-realm trust questions

On Tue, Dec 28, 2010 at 01:34:17PM -0800, Wilper, Ross A wrote: > > Our adjoin[0] script (which was referenced in a BigAdmin paper by Baban > > Kenkre[1]) implements a heuristic to detect what enctypes are available > > based on, IIRC, trying to add an LDAP attribute named > > "msDS-SupportedEncryp

RE: some cross-realm trust questions

-Original Message- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Nicolas Williams Sent: Tuesday, December 28, 2010 11:58 AM To: Victor Sudakov Cc: kerberos@mit.edu Subject: Re: some cross-realm trust questions Our adjoin[0] script (which was referenced in

Re: some cross-realm trust questions

On Tue, Dec 28, 2010 at 05:02:45PM +, Victor Sudakov wrote: > Russ Allbery wrote: > > You use a password. Enter the same password on both sides when creating > > the key, and then be sure to remove any extraneous enctypes on the Heimdal > > side that AD isn't configured to provide. > > Do you

Re: some cross-realm trust questions

Victor Sudakov writes: > Russ Allbery wrote: >> You use a password. Enter the same password on both sides when creating >> the key, and then be sure to remove any extraneous enctypes on the Heimdal >> side that AD isn't configured to provide. > Do you mean to say that the key derivation algorit

Re: some cross-realm trust questions

Russ Allbery wrote: [dd] > > But it still escapes me how on earth I will end up with > > krbtgt/unix.re...@windows.realm and krbtgt/windows.re...@unix.realm > > having the same key. There is nothing in the above articles about > > exporting and importing keytabs. > You use a password. Enter the

Re: some cross-realm trust questions

On Mon, Dec 27, 2010 at 05:20:19AM +, Victor Sudakov wrote: > That's great, but at least at the initialization stage, how is a > shared key for the corresponding krbtgt principals transferred between > the two KDCs? > > The Windows "New Trust" wizard just asks for a password and never > offers

Re: some cross-realm trust questions

Victor Sudakov writes: > I am just curious. What Windows client programs and Unix server programs > (or vice versa) must you use? How do you use this trust? We allow all Active Directory users at Stanford to log on either in the AD realm or in the university Heimdal realm, and try to set up as m

Re: some cross-realm trust questions

On Mon, Dec 27, 2010 at 05:20:19AM +, Victor Sudakov wrote: > Nicolas Williams wrote: > > > 1. If a cross-realm trust is configured, do the realms' KDCs ever have to > > > exchange any traffic between each other? > > > No, they do not. > > That&#x

Re: some cross-realm trust questions

Nicolas Williams wrote: > > 1. If a cross-realm trust is configured, do the realms' KDCs ever have to > > exchange any traffic between each other? > No, they do not. That's great, but at least at the initialization stage, how is a shared key for the corresponding krbt

Re: some cross-realm trust questions

nk the setup is substantially the > same. It's just like a regular bidirectional trust, except you would then > delete the krbtgt principal for the Active Directory realm from the > Heimdal realm. > There's a section in the Heimdal manual on setting up cross-realm trus

Re: some cross-realm trust questions

On Sat, Dec 25, 2010 at 07:10:53AM +, Victor Sudakov wrote: > 1. If a cross-realm trust is configured, do the realms' KDCs ever have to > exchange any traffic between each other? No, they do not. Nico -- Kerberos m

Re: some cross-realm trust questions

setup is substantially the same. It's just like a regular bidirectional trust, except you would then delete the krbtgt principal for the Active Directory realm from the Heimdal realm. There's a section in the Heimdal manual on setting up cross-realm trust. On the Active Directory side, I'v

some cross-realm trust questions

Colleagues, 1. If a cross-realm trust is configured, do the realms' KDCs ever have to exchange any traffic between each other? 2. Are there any success stories of servers in a Heimdal realm authenticating users from a trusted Microsoft AD based realm? Is there a documentation how to setup

Re: cross realm trust

IL PROTECTED] > > renew until 08/08/07 16:13:08, Flags: FRIA > > 08/07/07 16:13:31 08/08/07 07:13:10 krbtgt/[EMAIL PROTECTED] > > renew until 08/08/07 16:13:08, Flags: FRAT > > 08/07/07 16:13:31 08/08/07 07:13:10 host/[EMAIL PROTECTED] > >

Re: cross realm trust

gt; I have never set up a cross realm relationship between two realms, but > the logs and the tickets on the client look correct to me. > > I have double checked the password for the krbtgt/[EMAIL PROTECTED] > principals in both realms and am sure they match. Just in case I set up > t

cross realm trust

he password for the krbtgt/[EMAIL PROTECTED] principals in both realms and am sure they match. Just in case I set up the krbtgt/[EMAIL PROTECTED] principals in both realms. All 4 principals used to set up the cross realm trust have the same key version number, passwords, etc. The realms section of

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Achim As promised. On Wed, 2007-08-01 at 21:47 +0200, Achim Grolms wrote: > On Wednesday 01 August 2007 09:52, Mikkel Kruse Johnsen wrote: > > Hello Mikkel, > please provide me some more information. > > 1. You wrote you have successfully done delegation using another >Webclient. Pleas

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Achim As you can see the length of the token is different and in LWN the token is not expired. I think Douglas is right that the token is not delegated on firefox. Log LWN: [Tue Aug 07 09:28:28 2007] [debug] src/mod_auth_kerb.c(1518): [client 130.226.36.170] kerb_authenticate_user entered wi

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi All Here is the dump from Windows using firefox and IE7 I was thinking that maybe it could be a linking problem in mod_auth_kerb. Using both gssapi (cyrus-sasl) and kerberos5 (mit krb5). Here is the buidling process: [EMAIL PROTECTED] SPECS]$ rpmbuild -ba mod_auth_kerb.spec Executing(%prep

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Just found something. It seems that the ticket is expired, look at this patch (thanks Achim for pointing this out) [Mon Jul 30 15:19:55 2007] [debug] src/mod_auth_kerb.c(1488): [client 130.226.36.170] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Mon Jul 30 15:19:55

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Achim I see your point here is the ne patch. I still get this error: [Mon Jul 30 10:51:26 2007] [debug] src/mod_auth_kerb.c(1458): [client 130.226.36.170] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Mon Jul 30 10:51:26 2007] [debug] src/mod_auth_kerb.c(1458): [clien

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Henry B. Hotz wrote: > I think the Firefox pref overrides this, but if it's running on a > Windows platform with the native Kerberos (gsslib) then do we need to > check that the ok-as-delegate flag is set in the service ticket? I seem > to remember that it didn't matter except for IE. It mig

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Achim Grolms wrote: > On Friday 27 July 2007 18:11, Douglas E. Engert wrote: >> I stil think you have a client problem, of the client not delegating. > http://www.ietf.org/rfc/rfc1964.txt old and http://www.ietf.org/rfc/rfc4121.txt define the Kerberos/GSSAPI packets. With Kerberos the delegate

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Friday 27 July 2007 09:14, Mikkel Kruse Johnsen wrote: > After the patch (attached) I get this. I think your patch does my idea wrong. Your patch checks major_status == GSS_S_COMPLETE but in your patch major_status is the return-value of gss_display_name(), not of accept_sec_token. You ne

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

I think the Firefox pref overrides this, but if it's running on a Windows platform with the native Kerberos (gsslib) then do we need to check that the ok-as-delegate flag is set in the service ticket? I seem to remember that it didn't matter except for IE. On Jul 27, 2007, at 12:14 AM, Mikk

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Friday 27 July 2007 18:11, Douglas E. Engert wrote: > I stil think you have a client problem, of the client not delegating. A client not delegating because mutal-auth has not finished it's roundtrips? The mod_auth_kerb code tries to store the deleg_cred *without* checking if mutal-auth is in pr

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

I stil think you have a client problem, of the client not delegating. Can you use IE, or FireFox on some other platform to connecto your server? Mikkel Kruse Johnsen wrote: > Hi > > Settings check: > > network.negotiate-auth.allow-proxies = true > network.negotiate-auth.delegation-uris = cbs.d

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Settings check: network.negotiate-auth.allow-proxies = true network.negotiate-auth.delegation-uris = cbs.dk,hhk.dk network.negotiate-auth.gsslib = network.negotiate-auth.trusted-uris = cbs.dk,hhk.dk network.negotiate-auth.using-native-gsslib = true After the patch (attached) I get this. So it

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Nothing wrong with what you suggest, but in theory the conf- >krb_save_credentials value doesn't need to be checked. In practice, who knows? Lots of bugs out there. On Jul 26, 2007, at 1:38 PM, Achim Grolms wrote: > On Thursday 26 July 2007 21:54, Douglas E. Engert wrote: >> Achim Grolms wrot

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Thursday 26 July 2007 21:54, Douglas E. Engert wrote: > Achim Grolms wrote: > > On Thursday 26 July 2007 20:40, Henry B. Hotz wrote: > >>> If I understand RFC2744 correct GSS_C_DELEG_FLAG > >>> would not be set in that case? > >>> > >>> Achim > >> > >> Agreed. That flag shouldn't be set AFAIK,

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Jul 26, 2007, at 8:22 AM, Douglas E. Engert wrote: > Attached is the Wireshark print output of the GET request showing > the SPNEGO and GSSAPI > > In original trace, the client does request a ticket to delegate > but it looks like it is not delegating it. > > It looks like it is: > User-Agent:

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Thursday 26 July 2007 20:40, Henry B. Hotz wrote: > > If I understand RFC2744 correct GSS_C_DELEG_FLAG > > would not be set in that case? > > > > Achim > > Agreed. That flag shouldn't be set AFAIK, though the value isn't > valid until negotiation is complete. That means before trying to store

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Achim Grolms wrote: > On Thursday 26 July 2007 20:40, Henry B. Hotz wrote: > >>> If I understand RFC2744 correct GSS_C_DELEG_FLAG >>> would not be set in that case? >>> >>> Achim >> Agreed. That flag shouldn't be set AFAIK, though the value isn't >> valid until negotiation is complete. > > Tha

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Jul 26, 2007, at 11:28 AM, Achim Grolms wrote: > On Thursday 26 July 2007 20:16, Douglas E. Engert wrote: >> Achim Grolms wrote: > >>> From my point of view that means we can exclude the item >>> "Client sends nothing as delegated credeatials" because from >>> my point of view the logging mean

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Mikkel Kruse Johnsen wrote: > Hi Douglas > > I have already done all these steps. It still looks like the client is not delegating. and I am out of ideas. > > I'm currently on linux only to eliminate trust relations and the windows > factor :) > > I'm on Fedora 7 getting a ticket from MIT k

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Thursday 26 July 2007 20:16, Douglas E. Engert wrote: > Achim Grolms wrote: > > From my point of view that means we can exclude the item > > "Client sends nothing as delegated credeatials" because from > > my point of view the logging means *something* is received. > > No, the trace showed tha

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Thursday 26 July 2007 19:41, Douglas E. Engert wrote: > Mikkel Kruse Johnsen wrote: > > Hi Douglas > > > > I have already done all these steps. > > It still looks like the client is not delegating. I am not sure if this idea works but maybe you (Mikkel) can give it a try? >From my point of vi

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

One more idea... Achim Grolms wrote: > On Thursday 26 July 2007 19:41, Douglas E. Engert wrote: >> Mikkel Kruse Johnsen wrote: >>> Hi Douglas >>> >>> I have already done all these steps. >> It still looks like the client is not delegating. > > I am not sure if this idea works > but maybe you (Mi

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Douglas I have already done all these steps. I'm currently on linux only to eliminate trust relations and the windows factor :) I'm on Fedora 7 getting a ticket from MIT kerberos and accessing a web site using the same MIT kerberos. I regularly try on windows, It don't work either (have done

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Attached is the Wireshark print output of the GET request showing the SPNEGO and GSSAPI In original trace, the client does request a ticket to delegate but it looks like it is not delegating it. It looks like it is: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070718

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Douglas Im not sure what to look for, but here is the dump. If you are able to see anything. Done with wireshark. /Mikkel On Wed, 2007-07-25 at 09:36 -0500, Douglas E. Engert wrote: > Looks like it should have worked. > > A wireshark trace of the packets would show a lot, as long as > the s

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Achim With the patch applied: [Thu Jul 26 16:05:21 2007] [debug] src/mod_auth_kerb.c(1451): [client 130.226.36.170] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Thu Jul 26 16:05:21 2007] [debug] src/mod_auth_kerb.c(1451): [client 130.226.36.170] kerb_authenticate_use

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Jul 25, 2007, at 2:55 AM, Mikkel Kruse Johnsen wrote: >> Is the KRB5CCNAME being set in the environment of the subprocess. > > Don't know how to check this. The KRB5CCNAME is in the env. with > the attached patch but the credetials is never saved to that file. Protect CGI's and access a cgi

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Wednesday 25 July 2007 11:55, Mikkel Kruse Johnsen wrote: > Compiled the mod_auth_kerb with the attched The modification does a check if GSS_C_DELEG_FLAG is present. >From my point of view (a paranoid point of view) an additional check has to follow: before the code does the call to store_gss

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

On Mon, 2007-07-23 at 16:27 -0500, Douglas E. Engert wrote: > > Mikkel Kruse Johnsen wrote: > > Hi Markus > > > > Yes that is what I want. I need the KRB5CCNAME (the credential) so I can > > login to my OpenLDAP SASL based server and PostgreSQL with kerberos. > > So what you need is the Kerb

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Looks like it should have worked. A wireshark trace of the packets would show a lot, as long as the session is not encrypted. It could be a size issue. AD can produce very large tickets if you are in many groups. It could be an enc-type issue, which the server does not understand It could be th

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Mikkel Kruse Johnsen wrote: > Hi Markus > > Yes that is what I want. I need the KRB5CCNAME (the credential) so I can > login to my OpenLDAP SASL based server and PostgreSQL with kerberos. So what you need is the Kerberos credentials. I have an older version of mod_auth_kerb I assume your vers

Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

Hi Markus Yes that is what I want. I need the KRB5CCNAME (the credential) so I can login to my OpenLDAP SASL based server and PostgreSQL with kerberos. /Mikkel On Mon, 2007-07-23 at 19:33 +0100, Markus Moeller wrote: >  > > Storing credentials in a krb5 cache pointing to KRB5CCNAME has nothi

Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Mikkel Kruse Johnsen wrote: > Hi Douglas > > Setting: "ksetup /SetRealmFlag CBS.DK Delegate" did not work. Still no > KRB5CCNAME in apache. > > I have recompiled krb5-1.5 (RHEL5) with a patch to make it possible to > set the ok-as-delegate flag. I then set the flag on > "HTTP/[EMAIL PROTECTE

Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Hi Douglas Setting: "ksetup /SetRealmFlag CBS.DK Delegate" did not work. Still no KRB5CCNAME in apache. I have recompiled krb5-1.5 (RHEL5) with a patch to make it possible to set the ok-as-delegate flag. I then set the flag on "HTTP/[EMAIL PROTECTED]" and windows kerbtray shows "Ok as delegate"

Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Stephen Frost wrote: > * Mikkel Kruse Johnsen ([EMAIL PROTECTED]) wrote: >> Now I only have the problem that mod_auth_kerb don't write my >> credentials to KRB5CCNAME (in PHP). >> >> My "kerbtray" under windows says it is Forwardable but no "Ok to >> delegate", So I guess that is the problem. H

Re: Negotiate on Windows with cross-realm trust AD and MIT Kereros.

You asked how to do this is AD... An AD admin set the TRUSTED_FOR_DELEGATION in UserAccountControl for the server. But not just any admin can set this, who can set the bit is controlled by a group control policy on the DC. In 2000 you had to edit a file. In 2003 there is a way to set it see belo

Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Hi The problem is that my HTTP/[EMAIL PROTECTED] is made on the MIT kerberos server and not the AD. So I have to set the ok-as-delegate on the MIT server, but according to Stehpen that is not possible: Question: I found how to set ok-as-delegate for heimdal how is this done for MIT kerberos ? A

Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

* Mikkel Kruse Johnsen ([EMAIL PROTECTED]) wrote: > Now I only have the problem that mod_auth_kerb don't write my > credentials to KRB5CCNAME (in PHP). > > My "kerbtray" under windows says it is Forwardable but no "Ok to > delegate", So I guess that is the problem. > > Under linux they are forwar

Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

On Wednesday 18 July 2007 10:01, Mikkel Kruse Johnsen wrote: > Now I only have the problem that mod_auth_kerb don't write my > credentials to KRB5CCNAME (in PHP). Some knowledge on Credentials delegation I have stolen from mailinglists is now part of

Re: Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Hi All That did the trick, recompiling krb5-1.5 (on RHEL5 64bit) with that patch. Now I only have the problem that mod_auth_kerb don't write my credentials to KRB5CCNAME (in PHP). My "kerbtray" under windows says it is Forwardable but no "Ok to delegate", So I guess that is the problem. Under l

Re: Negotiate on Windows with cross-realm trust AD and MIT Kereros.

On Tuesday 17 July 2007 09:41, Mikkel Kruse Johnsen wrote: > gss_accept_sec_context() failed: Unspecified GSS failure. Minor code > may provide more information (Cannot allocate memory) What OS and what Kerberoslibs do you use? Background of this question: I've seen this errormessage "Cannot al

Re: Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Hi Yes that did the trick. netdom trust HHK.DK /domain:CBS.DK /foresttransitive:yes netdom trust HHK.DK /domain:CBS.DK /addtln:cbs.dk This is very cool, now the windows clients get the HTTP/[EMAIL PROTECTED] when using [EMAIL PROTECTED] The problem is now that I get this: [Tue Jul 17 09:33:34

Re: Negotiate on Windows with cross-realm trust AD and MIT Kereros.

I think you need to tell AD that keys for systems in the cbs.dk domain can be retrieved frpm CBS.DK. Try netdom trust HHK.DK /domain:CBS.DK /addtln:cbs.dk on your kdc. Markus "Mikkel Kruse Johnsen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi Everyone > > What I want to

Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Hi Everyone What I want to do is to be able to athenticate (Negotiate) from firefox, IE7 on Windows and Linux. What I have is an MS Active Directory 2003 (but running in 2000 mode) with realm "HHK.DK" then I have a Linux Kerberos server (RHEL5 64bit) with realm "CBS.DK". I have made a two-way tru

Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Mikkel Kruse Johnsen wrote: > Hi All > > Still haven't fixed this, but after reading more about it, I found > someone who said that Microsoft when implementing the Kerberos protocol > had changed something (big surprise) and instead of making it the > clients job to figure out whitch server to c

Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

Hi All Still haven't fixed this, but after reading more about it, I found someone who said that Microsoft when implementing the Kerberos protocol had changed something (big surprise) and instead of making it the clients job to figure out whitch server to contact they made it the servers job. Meani

Re: Cross Realm Trust with stand alone Windows Workstation

Thomas Lubanski wrote: > Hi, > > I've run into a problem with the cross realm trust and Windows Workstations. > The setup is as follows: > Windows Workstation stand-alone with XP. The department owning the > workstation is doing their own adminsitration. The > centra

Cross Realm Trust with stand alone Windows Workstation

Hi, I've run into a problem with the cross realm trust and Windows Workstations. The setup is as follows: Windows Workstation stand-alone with XP. The department owning the workstation is doing their own adminsitration. The central department is running AD. The Workstation should not be imp

Re: AD Cross Realm Trust Integration

Greetings again, > > Windows server support for cross realm trusts using RC4 keys was added > to 2003 SP1. When you are ready to install it, you can upgrade your > cross realm keys to RC4. Gotcha...I was hoping this would be the case. Now if I can only convince the 800 departments on campus

Re: AD Cross Realm Trust Integration

John Harris wrote: > Greetings, > > We're currently looking at increasing the session and ticket encryption > types for our Unix-based Kerberos clients (command-line and GSSAPI-based > client/web clients) up to AES. > > One of our issues is to continue to support the cross-realm authentication >

AD Cross Realm Trust Integration

Greetings, We're currently looking at increasing the session and ticket encryption types for our Unix-based Kerberos clients (command-line and GSSAPI-based client/web clients) up to AES. One of our issues is to continue to support the cross-realm authentication with Windows KDCs on campus. As fa

Re: kinit to a kdc having a cross-realm trust

the KDC of realm TWO.NET where he isn't defined but the two KDCs having set up a cross-realm trust between them? It does not work like that. The user authenticates in his own realm and gets a TGT. When he want to use a server that is the other realm, the libs use the user's TGT to get a c

kinit to a kdc having a cross-realm trust

TWO.NET where he isn't defined but the two KDCs having set up a cross-realm trust between them? If I try this in a test setup, the KDC of realm TWO.NET says kinit(v5): Client not found in Kerberos database while getting initial credentials As far as I understood the cross-realm mechanism

Re: AW: Windows AD and MIT KDC Cross-Realm Trust

"Schikora, Dominik" wrote: > > HI > > > > We manage to achieve that User with a mapped Principal can > > login on a > > > client in the AD with the MIT Realm Principal and Password. > > He gets a > > > tgt for the MIT realm and one for the AD 2003 Domain. But > > if the same > > > user login on

AW: Windows AD and MIT KDC Cross-Realm Trust

HI > > We manage to achieve that User with a mapped Principal can > login on a > > client in the AD with the MIT Realm Principal and Password. > He gets a > > tgt for the MIT realm and one for the AD 2003 Domain. But > if the same > > user login on a client in the AD with the Principal and

Re: Windows AD and MIT KDC Cross-Realm Trust

"Schikora, Dominik" wrote: > > Hallo everyone > > Douglas E.Engert wrote: > > > That is not the way it works. The user would login with user at > KERB.UTA.EDU > > and get a ticket, krbtgt/KERB.UTA.EDU at KERB.UTA.EDU. This is done > from the > > Kerberos realm. Then when the user needed to acc

Re: Windows AD and MIT KDC Cross-Realm Trust

> > Hallo > > This is mainly a question for Mr. Douglas E.Engert but if anyone else > can help please feel free to do so. > We have a similar organisation as the "opposite" and I can't figure out > how to accomplish the following: > We will users in the AD 2003 domain authenticate to Windows an

Windows AD and MIT KDC Cross-Realm Trust

Hallo everyone Douglas E.Engert wrote: > That is not the way it works. The user would login with user at KERB.UTA.EDU > and get a ticket, krbtgt/KERB.UTA.EDU at KERB.UTA.EDU. This is done from the > Kerberos realm. Then when the user needed to access a Windows resource, such > as the local works

Re: Problem with cross realm trust and udp between AD and MIT

Hey Russ! It *may* be sufficient to set: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\MYREALM This is a dword, and the bit you need set is 0x02 See: http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/rege

Re: Problem with cross realm trust and udp between AD and MIT

Thanks for your response. I don't see the /SetRealmFlags on my version of KSETUP? Do I need a specific version? Here are the switches I see: ksetup /? USAGE: /SetRealm DnsDomainName -- set name of RFC1510 Kerberos Realm /MapUser Principal Account -- Map Kerberos Principal to account (* = any/all)

Re: Problem with cross realm trust and udp between AD and MIT

Have you turned on TCP support on the MIT KDC? You need to use MIT KDC 1.3.x; turn on TCP support; and set the TcpSupported flag on the MIT realm with KSETUP. Jeffrey Altman Russell Shapiro wrote: > I have a one way trust between AD KDC and MIT KDC, where MIT trusts > AD. This seems to mostly w

Problem with cross realm trust and udp between AD and MIT

I have a one way trust between AD KDC and MIT KDC, where MIT trusts AD. This seems to mostly work where windows clients can retrieve MIT service tickets. There are some windows accounts, however, where I believe there are too many groups which causes problems. When trying to get a service ticket fr

  1   2   >