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

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

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

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.

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

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,

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,

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

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:

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

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

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 member

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

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 how I can

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 inter

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 importing

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 as

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 same

Re: some cross-realm trust questions

Victor Sudakov v...@mpeks.no-spam-here.tomsk.su 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

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 mean to

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

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

Re: some cross-realm trust questions

. 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've not done it personally

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 krbtgt principals transferred between

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's great, but at least at the initialization stage, how

Re: some cross-realm trust questions

Victor Sudakov v...@mpeks.no-spam-here.tomsk.su 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

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 to

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: some cross-realm trust questions

, but I think 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 trust. On the Active Directory side

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 mailing list Kerberos

Re: cross realm trust

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 /etc/krb5

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. Please send

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):

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

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 =

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

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,

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

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 delegated

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 might

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 view that

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. That means before

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.

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 kerberos

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 that the

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 (Mikkel) can give

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.

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 wrote:

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 delegated

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

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]

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, though the value isn't

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

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 Kerberos

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

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.

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 PROTECTED]

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 nothing

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 version

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

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: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.

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

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 ?

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

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. Have a look at

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.

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

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 central department is running AD

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: 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 cross realm

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

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 and then

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 access a Windows

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 (* =

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:

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

RE: Windows AD and MIT KDC Cross-Realm Trust

That being the case, when a user tries to login using [EMAIL PROTECTED], I do see a request hit the KDC but the user still does not get logged in. According to the logs, I see an AS_REQ [EMAIL PROTECTED] for krbtgt/[EMAIL PROTECTED]. Yes that is the first step. This would then be

RE: Windows AD and MIT KDC Cross-Realm Trust

That is not the way it works. The user would login with [EMAIL PROTECTED] and get a ticket, krbtgt/[EMAIL PROTECTED] This is done from the Kerberos realm. Then when the user needed to access a Windows resource, such as the local workstation during login, A cross realm ticket would be

Re: Windows AD and MIT KDC Cross-Realm Trust

Digant Kasundra wrote: I think that's one of the ways you can do it, but that setup isn't considered pass-through authentication, which is what we are going for. That is the only way to do it. There is no term called pass-through authentication within Kerberos. The authentication between

RE: Windows AD and MIT KDC Cross-Realm Trust

That is the only way to do it. There is no term called pass-through authentication within Kerberos. The authentication between the MIT and Microsoft realms are based on cross-realm trusts. This is exactly what is described on the page: I guess I am using the phrase pass-through

Re: Windows AD and MIT KDC Cross-Realm Trust

Digant Kasundra wrote: That is the only way to do it. There is no term called pass-through authentication within Kerberos. The authentication between the MIT and Microsoft realms are based on cross-realm trusts. This is exactly what is described on the page: I guess I am using

Windows AD and MIT KDC Cross-Realm Trust

Hello everyone, I have found plenty of step by step instructions on this but we have failed to get them to work. Here is what I've got: We have a windows domain (UTA.EDU) and a kerberos realm (KERB.UTA.EDU). We want to test pass-through authentication on the Windows side so that when windows

RE: Windows AD and MIT KDC Cross-Realm Trust

To: [EMAIL PROTECTED] Subject: Windows AD and MIT KDC Cross-Realm Trust Hello everyone, I have found plenty of step by step instructions on this but we have failed to get them to work. Here is what I've got: We have a windows domain (UTA.EDU) and a kerberos realm (KERB.UTA.EDU). We

Re: Windows AD and MIT KDC Cross-Realm Trust

Digant Kasundra wrote: Hello everyone, I have found plenty of step by step instructions on this but we have failed to get them to work. Here is what I've got: We have a windows domain (UTA.EDU) and a kerberos realm (KERB.UTA.EDU). We want to test pass-through authentication on the

Re: Cross-realm trust

Philippe == Philippe Perrin [EMAIL PROTECTED] writes: Philippe Hello Philippe I'm now willing to allow users authenticated in REALM1 to use services of Philippe REALM2. I configured everything as I think I should have, and then I made a Philippe user authenticate in REALM1, and

Re: Cross-realm trust

In regard to: Re: Cross-realm trust, Sam Hartman said (at 1:24pm on Feb 15,...: Philippe == Philippe Perrin [EMAIL PROTECTED] writes: Philippe Hello Philippe I'm now willing to allow users authenticated in REALM1 to use services of Philippe REALM2. I configured everything as I

Re: Cross-realm trust

Tim Mooney [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] In regard to: Re: Cross-realm trust, Sam Hartman said (at 1:24pm on Feb 15,...: Philippe == Philippe Perrin [EMAIL PROTECTED] writes: Philippe Hello Philippe I'm now willing to allow users

Cross-realm trust

Hello I'm now willing to allow users authenticated in REALM1 to use services of REALM2. I configured everything as I think I should have, and then I made a user authenticate in REALM1, and used a telnet server in REALM2. The only way I found to make it work was to add a ~/.k5login file