Re: Deploy module

[Russ Allbery]

Techie  writes:

> I have compiled the eyrie pam_krb5 module for my RHEL boxes. I have
> many boxes running RHEL, some running 32 bit, some running 64bit.
> My question is this.. for all by 32bit boxes running the same version
> of RHEL, can I compile or build the libraries on a single box and
> deploy to like boxes?

Yes.  You should be able to run the built binary on any box with the same
RHEL release and architecture.

> Or do I need to configure, make, make install the pam_krb5 module for
> every box? I am assuming I can deploy the module but I may need to do
> something with libtool first as the make install mentions.

You can ignore that bit.  It's only there because I don't know how to shut
up libtool.  That part is only for public shared libraries, not for
modules.

-- 
Russ Allbery (r...@stanford.edu) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Deploy module

[Techie]

Hi there,

I have compiled the eyrie pam_krb5 module for my RHEL boxes. I have
many boxes running RHEL, some running 32 bit, some running 64bit.
My question is this.. for all by 32bit boxes running the same version
of RHEL, can I compile or build the libraries on a single box and
deploy to like boxes? Or do I need to configure, make, make install
the pam_krb5 module for every box? I am assuming I can deploy the
module but I may need to do something with libtool first as the make
install mentions.


Thank you

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Establishing and verifying a trust between Unix MIT KDC and Windows Server 2003 AD

[Wilper, Ross A]

I do not think that you can use netdom /verify with an external Kerberos trust, 
unfortunately.

If the registry value checks out on all the Domain controllers and the client, 
then it's probably elsewhere.
You could also try the "RealmFlags" value 
http://technet.microsoft.com/en-us/library/cc736698(WS.10).aspx depending on 
your external realm's settings.

-Ross

From: N K [mailto:nkalus...@gmail.com]
Sent: Tuesday, August 03, 2010 4:10 PM
To: Wilper, Ross A
Cc: kerberos@MIT.EDU
Subject: Re: Establishing and verifying a trust between Unix MIT KDC and 
Windows Server 2003 AD

Ye,s I did use the ksetup command on the Windows machine to add the MIT KDC..
On Tue, Aug 3, 2010 at 4:08 PM, Wilper, Ross A 
mailto:rwil...@stanford.edu>> wrote:
For #3...

Windows Kerberos libraries do not look at krb5.ini/krb5.conf to find external 
KDCs, they look in the registry
HKLM/SYSTEM/CurrentControlSet/Control/LSA/Kerberos/Domains/
REG_MULTI_SZ KdcNames

(This registry key is populated by the Windows ksetup command)

For #5...
Yes, if needed.

-Ross

From: N K [mailto:nkalus...@gmail.com]
Sent: Tuesday, August 03, 2010 4:04 PM
To: Wilper, Ross A
Cc: kerberos@MIT.EDU
Subject: Re: Establishing and verifying a trust between Unix MIT KDC and 
Windows Server 2003 AD

Hi Ross,

Thank you very much for your prompt response. A number of things that I have 
tried so far:

1) Incorrect passphrase for one of the three trust accounts
   >> Will look at this
2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
  >> specified the encryption type in the kdc.conf file and used the "cpw" 
command to change the password of principals and re-generate the keys using the 
specified encryption

3) Client machine cannot resolve the MIT KDCs
   >> Have included the mit kdc info in the client machine's krb5.ini file 
and updated DNS information with the unix kerberos realm. However, the netdom 
tool returns something like:
   netdom trust  /Domain: /verify /kerberos 
/verbose

  Establishing a session with \\

  Reading LSA domain policy information

  Unable to contact the domain 

  Deleting the session with \\

   The command failed to complete successfully.

4) Duplicate mappings on user accounts in the same AD domain
   (do an ldap search on altSecurityIdentities)
 >> Will take a look at this

5) You may need to set TLN mappings (referrals) on one side or the other
>> Using the netdom ... /addtln command ?

6) If you have multiple domains, is the realm trust set transitive?
>> Yes, the trust is transitive.

Regards,
Nivedita

On Tue, Aug 3, 2010 at 3:37 PM, Wilper, Ross A 
mailto:rwil...@stanford.edu>> wrote:
Unfortunately, there are a lot of reasons that this could fail.

1) Incorrect passphrase for one of the three trust accounts
2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
3) Client machine cannot resolve the MIT KDCs
4) Duplicate mappings on user accounts in the same AD domain
   (do an ldap search on altSecurityIdentities)
5) You may need to set TLN mappings (referrals) on one side or the other
6) If you have multiple domains, is the realm trust set transitive?

Probably more. The only times I've had failures were case #1 and #3

Also note that MIT credentials will always fail to logon to RDP when NLA is in 
use.

-Ross

-Original Message-
From: kerberos-boun...@mit.edu 
[mailto:kerberos-boun...@mit.edu] On Behalf Of 
N K
Sent: Tuesday, August 03, 2010 3:19 PM
To: kerberos@MIT.EDU
Subject: Establishing and verifying a trust between Unix MIT KDC and Windows 
Server 2003 AD

Hi all,

I followed the steps for a cross-realm setup between the MIT KDC and AD
according to O'reilly's Definitive Guide book:

- specifying KDC's using ksetup on the participating Windows machines

- creating principals krbtgt/dom...@realm and krbtgt/re...@domain in the MIT
KDC

- creating a 2 way trust in the AD

- mapping an AD user to a user in the MIT KDC

However, when I try to logon to the Kerberos realm from a Windows machine
using the credentials of the MIT KDC user, I get an error that the system
could not log me on because the username or domain is incorrect.

Has anyone come across a similar problem before?

Thanks much in advance,

Nivedita.

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: Establishing and verifying a trust between Unix MIT KDC and Windows Server 2003 AD

[N K]

Ye,s I did use the ksetup command on the Windows machine to add the MIT
KDC..

On Tue, Aug 3, 2010 at 4:08 PM, Wilper, Ross A  wrote:

>  For #3…
>
>
>
> Windows Kerberos libraries do not look at krb5.ini/krb5.conf to find
> external KDCs, they look in the registry
>
> HKLM/SYSTEM/CurrentControlSet/Control/LSA/Kerberos/Domains/
>
> REG_MULTI_SZ KdcNames
>
>
>
> (This registry key is populated by the Windows ksetup command)
>
>
>
> For #5…
>
> Yes, if needed.
>
>
>
> -Ross
>
>
>
> *From:* N K [mailto:nkalus...@gmail.com]
> *Sent:* Tuesday, August 03, 2010 4:04 PM
> *To:* Wilper, Ross A
> *Cc:* kerberos@MIT.EDU
> *Subject:* Re: Establishing and verifying a trust between Unix MIT KDC and
> Windows Server 2003 AD
>
>
>
> Hi Ross,
>
>
>
> Thank you very much for your prompt response. A number of things that I
> have tried so far:
>
>
>
> 1) Incorrect passphrase for one of the three trust accounts
>
>>> Will look at this
>
> 2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
>
>   >> specified the encryption type in the kdc.conf file and used the
> "cpw" command to change the password of principals and re-generate the keys
> using the specified encryption
>
>
> 3) Client machine cannot resolve the MIT KDCs
>
>>> Have included the mit kdc info in the client machine's krb5.ini
> file and updated DNS information with the unix kerberos realm. However,
> the netdom tool returns something like:
>
>netdom trust  /Domain: /verify /kerberos
> /verbose
>
>   Establishing a session with \\
>
>   Reading LSA domain policy information
>
>   Unable to contact the domain 
>
>   Deleting the session with \\
>
>The command failed to complete successfully.
>
>
> 4) Duplicate mappings on user accounts in the same AD domain
>(do an ldap search on altSecurityIdentities)
>
>  >> Will take a look at this
>
>
> 5) You may need to set TLN mappings (referrals) on one side or the other
>
> >> Using the netdom ... /addtln command ?
>
>
> 6) If you have multiple domains, is the realm trust set transitive?
>
> >> Yes, the trust is transitive.
>
>
> Regards,
>
> Nivedita
>
>
>
> On Tue, Aug 3, 2010 at 3:37 PM, Wilper, Ross A 
> wrote:
>
> Unfortunately, there are a lot of reasons that this could fail.
>
> 1) Incorrect passphrase for one of the three trust accounts
> 2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
> 3) Client machine cannot resolve the MIT KDCs
> 4) Duplicate mappings on user accounts in the same AD domain
>(do an ldap search on altSecurityIdentities)
> 5) You may need to set TLN mappings (referrals) on one side or the other
> 6) If you have multiple domains, is the realm trust set transitive?
>
> Probably more. The only times I've had failures were case #1 and #3
>
> Also note that MIT credentials will always fail to logon to RDP when NLA is
> in use.
>
> -Ross
>
>
> -Original Message-
> From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf
> Of N K
> Sent: Tuesday, August 03, 2010 3:19 PM
> To: kerberos@MIT.EDU
> Subject: Establishing and verifying a trust between Unix MIT KDC and
> Windows Server 2003 AD
>
> Hi all,
>
> I followed the steps for a cross-realm setup between the MIT KDC and AD
> according to O'reilly's Definitive Guide book:
>
> - specifying KDC's using ksetup on the participating Windows machines
>
> - creating principals krbtgt/dom...@realm and krbtgt/re...@domain in the
> MIT
> KDC
>
> - creating a 2 way trust in the AD
>
> - mapping an AD user to a user in the MIT KDC
>
> However, when I try to logon to the Kerberos realm from a Windows machine
> using the credentials of the MIT KDC user, I get an error that the system
> could not log me on because the username or domain is incorrect.
>
> Has anyone come across a similar problem before?
>
> Thanks much in advance,
>
> Nivedita.
>
> 
> 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: Establishing and verifying a trust between Unix MIT KDC and Windows Server 2003 AD

[Wilper, Ross A]

For #3...

Windows Kerberos libraries do not look at krb5.ini/krb5.conf to find external 
KDCs, they look in the registry
HKLM/SYSTEM/CurrentControlSet/Control/LSA/Kerberos/Domains/
REG_MULTI_SZ KdcNames

(This registry key is populated by the Windows ksetup command)

For #5...
Yes, if needed.

-Ross

From: N K [mailto:nkalus...@gmail.com]
Sent: Tuesday, August 03, 2010 4:04 PM
To: Wilper, Ross A
Cc: kerberos@MIT.EDU
Subject: Re: Establishing and verifying a trust between Unix MIT KDC and 
Windows Server 2003 AD

Hi Ross,

Thank you very much for your prompt response. A number of things that I have 
tried so far:

1) Incorrect passphrase for one of the three trust accounts
   >> Will look at this
2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
  >> specified the encryption type in the kdc.conf file and used the "cpw" 
command to change the password of principals and re-generate the keys using the 
specified encryption

3) Client machine cannot resolve the MIT KDCs
   >> Have included the mit kdc info in the client machine's krb5.ini file 
and updated DNS information with the unix kerberos realm. However, the netdom 
tool returns something like:
   netdom trust  /Domain: /verify /kerberos 
/verbose

  Establishing a session with \\

  Reading LSA domain policy information

  Unable to contact the domain 

  Deleting the session with \\

   The command failed to complete successfully.

4) Duplicate mappings on user accounts in the same AD domain
   (do an ldap search on altSecurityIdentities)
 >> Will take a look at this

5) You may need to set TLN mappings (referrals) on one side or the other
>> Using the netdom ... /addtln command ?

6) If you have multiple domains, is the realm trust set transitive?
>> Yes, the trust is transitive.

Regards,
Nivedita

On Tue, Aug 3, 2010 at 3:37 PM, Wilper, Ross A 
mailto:rwil...@stanford.edu>> wrote:
Unfortunately, there are a lot of reasons that this could fail.

1) Incorrect passphrase for one of the three trust accounts
2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
3) Client machine cannot resolve the MIT KDCs
4) Duplicate mappings on user accounts in the same AD domain
   (do an ldap search on altSecurityIdentities)
5) You may need to set TLN mappings (referrals) on one side or the other
6) If you have multiple domains, is the realm trust set transitive?

Probably more. The only times I've had failures were case #1 and #3

Also note that MIT credentials will always fail to logon to RDP when NLA is in 
use.

-Ross

-Original Message-
From: kerberos-boun...@mit.edu 
[mailto:kerberos-boun...@mit.edu] On Behalf Of 
N K
Sent: Tuesday, August 03, 2010 3:19 PM
To: kerberos@MIT.EDU
Subject: Establishing and verifying a trust between Unix MIT KDC and Windows 
Server 2003 AD

Hi all,

I followed the steps for a cross-realm setup between the MIT KDC and AD
according to O'reilly's Definitive Guide book:

- specifying KDC's using ksetup on the participating Windows machines

- creating principals krbtgt/dom...@realm and krbtgt/re...@domain in the MIT
KDC

- creating a 2 way trust in the AD

- mapping an AD user to a user in the MIT KDC

However, when I try to logon to the Kerberos realm from a Windows machine
using the credentials of the MIT KDC user, I get an error that the system
could not log me on because the username or domain is incorrect.

Has anyone come across a similar problem before?

Thanks much in advance,

Nivedita.

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: Establishing and verifying a trust between Unix MIT KDC and Windows Server 2003 AD

[N K]

Hi Ross,

Thank you very much for your prompt response. A number of things that I have
tried so far:

1) Incorrect passphrase for one of the three trust accounts
   >> Will look at this
2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
  >> specified the encryption type in the kdc.conf file and used the
"cpw" command to change the password of principals and re-generate the keys
using the specified encryption

3) Client machine cannot resolve the MIT KDCs
   >> Have included the mit kdc info in the client machine's krb5.ini
file and updated DNS information with the unix kerberos realm. However,
the netdom tool returns something like:
   netdom trust  /Domain: /verify /kerberos
/verbose

  Establishing a session with \\

  Reading LSA domain policy information

  Unable to contact the domain 

  Deleting the session with \\

   The command failed to complete successfully.

4) Duplicate mappings on user accounts in the same AD domain
   (do an ldap search on altSecurityIdentities)
 >> Will take a look at this

5) You may need to set TLN mappings (referrals) on one side or the other
>> Using the netdom ... /addtln command ?

6) If you have multiple domains, is the realm trust set transitive?
>> Yes, the trust is transitive.

Regards,
Nivedita

On Tue, Aug 3, 2010 at 3:37 PM, Wilper, Ross A  wrote:

> Unfortunately, there are a lot of reasons that this could fail.
>
> 1) Incorrect passphrase for one of the three trust accounts
> 2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
> 3) Client machine cannot resolve the MIT KDCs
> 4) Duplicate mappings on user accounts in the same AD domain
>(do an ldap search on altSecurityIdentities)
> 5) You may need to set TLN mappings (referrals) on one side or the other
> 6) If you have multiple domains, is the realm trust set transitive?
>
> Probably more. The only times I've had failures were case #1 and #3
>
> Also note that MIT credentials will always fail to logon to RDP when NLA is
> in use.
>
> -Ross
>
> -Original Message-
> From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf
> Of N K
> Sent: Tuesday, August 03, 2010 3:19 PM
> To: kerberos@MIT.EDU
> Subject: Establishing and verifying a trust between Unix MIT KDC and
> Windows Server 2003 AD
>
> Hi all,
>
> I followed the steps for a cross-realm setup between the MIT KDC and AD
> according to O'reilly's Definitive Guide book:
>
> - specifying KDC's using ksetup on the participating Windows machines
>
> - creating principals krbtgt/dom...@realm and krbtgt/re...@domain in the
> MIT
> KDC
>
> - creating a 2 way trust in the AD
>
> - mapping an AD user to a user in the MIT KDC
>
> However, when I try to logon to the Kerberos realm from a Windows machine
> using the credentials of the MIT KDC user, I get an error that the system
> could not log me on because the username or domain is incorrect.
>
> Has anyone come across a similar problem before?
>
> Thanks much in advance,
>
> Nivedita.
> 
> 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: UDP and fragmentation

[Jeffrey Altman]

 Many VPNs are built into routers that support stateful packet
inspection as part of the firewall.  If the VPN is IPSec based, the MTU
on the vpn connection is typically 152 octets smaller than the MTU on
the networks it connects.  As a result any packet that is larger than
this smaller MTU size must be fragmented.  Unfortunately, many of the
routers are configured to drop fragmented UDP packets because
reconstructing the packets to pass them through the stateful packet
inspection algorithms in one piece requires memory and cpu resources
which when used for this purpose would hinder overall throughput statistics.

To answer your question, the KDC does not see the fragmentation.  It
often doesn't see the packets at all or only sees the first fragment of
the message which is insufficient to generate a response.

Jeffrey Altman


On 8/2/2010 1:42 AM, Victor Sudakov wrote:
> Colleagues,
>
> Quoting from http://support.microsoft.com/kb/244474/
> By default, Kerberos uses connectionless UDP datagram packets.
> Depending on a variety of factors including security identifier (SID)
> history and group membership, some accounts will have larger Kerberos
> authentication packet sizes. Depending on the virtual private network
> (VPN) hardware configuration, these larger packets have to be
> fragmented when going through a VPN. The problem is caused by
> fragmentation of these large UDP Kerberos packets. Because UDP is a
> connectionless protocol, fragmented UDP packets will be dropped if
> they arrive at the destination out of order.
>
> Quoting from
> http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx
> A common problem is that routers will arbitrarily fragment UDP
> packets; when this happens the Kerberos ticket request packets are
> discarded by the KDC. 
>
> Please tell me how on earth does the KDC know that the packet has been
> fragmented? Packets are fragmented and reassembled on the network
> level (IP level), the fragmentation process should be opaque to UDP
> and the application, shouldn't it? 
>
> I assume the KDC should just receive data from the socket, no matter
> if the datagram was bigger than the MTU, is it correct?
>
> TIA.
>


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Establishing and verifying a trust between Unix MIT KDC and Windows Server 2003 AD

[Wilper, Ross A]

Unfortunately, there are a lot of reasons that this could fail.

1) Incorrect passphrase for one of the three trust accounts
2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
3) Client machine cannot resolve the MIT KDCs
4) Duplicate mappings on user accounts in the same AD domain
(do an ldap search on altSecurityIdentities)
5) You may need to set TLN mappings (referrals) on one side or the other
6) If you have multiple domains, is the realm trust set transitive?

Probably more. The only times I've had failures were case #1 and #3

Also note that MIT credentials will always fail to logon to RDP when NLA is in 
use.

-Ross

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of N 
K
Sent: Tuesday, August 03, 2010 3:19 PM
To: kerberos@MIT.EDU
Subject: Establishing and verifying a trust between Unix MIT KDC and Windows 
Server 2003 AD

Hi all,

I followed the steps for a cross-realm setup between the MIT KDC and AD
according to O'reilly's Definitive Guide book:

- specifying KDC's using ksetup on the participating Windows machines

- creating principals krbtgt/dom...@realm and krbtgt/re...@domain in the MIT
KDC

- creating a 2 way trust in the AD

- mapping an AD user to a user in the MIT KDC

However, when I try to logon to the Kerberos realm from a Windows machine
using the credentials of the MIT KDC user, I get an error that the system
could not log me on because the username or domain is incorrect.

Has anyone come across a similar problem before?

Thanks much in advance,

Nivedita.

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

Establishing and verifying a trust between Unix MIT KDC and Windows Server 2003 AD

[N K]

Hi all,

I followed the steps for a cross-realm setup between the MIT KDC and AD
according to O'reilly's Definitive Guide book:

- specifying KDC's using ksetup on the participating Windows machines

- creating principals krbtgt/dom...@realm and krbtgt/re...@domain in the MIT
KDC

- creating a 2 way trust in the AD

- mapping an AD user to a user in the MIT KDC

However, when I try to logon to the Kerberos realm from a Windows machine
using the credentials of the MIT KDC user, I get an error that the system
could not log me on because the username or domain is incorrect.

Has anyone come across a similar problem before?

Thanks much in advance,

Nivedita.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Certs For Use With Kinit

[Bram Cymet]

Hi,

Has anyone been able to successfully generate certs using openssl as
described here:
http://mailman.mit.edu/pipermail/krbdev/2006-November/005180.html

If so would you be able to show me examples of config files and commands
that you used?

Thanks,

-- 
Bram Cymet
Software Developer
Canadian Bank Note Co. Ltd.
Cell: 613-608-9752



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: UDP and fragmentation

[Greg Hudson]

On Mon, 2010-08-02 at 01:42 -0400, Victor Sudakov wrote:
> Please tell me how on earth does the KDC know that the packet has been
> fragmented? Packets are fragmented and reassembled on the network
> level (IP level), the fragmentation process should be opaque to UDP
> and the application, shouldn't it? 

Yes, it should.

It's possible that there are cases where one IP-layer network device
fragments the packets and another IP-layer network device throws away
fragments (if the fragments are received out of order, or all of the
time).  But the KDC process does not care whether a UDP packet was
fragmented or not.



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

UDP and fragmentation

[Victor Sudakov]

Colleagues,

Quoting from http://support.microsoft.com/kb/244474/
By default, Kerberos uses connectionless UDP datagram packets.
Depending on a variety of factors including security identifier (SID)
history and group membership, some accounts will have larger Kerberos
authentication packet sizes. Depending on the virtual private network
(VPN) hardware configuration, these larger packets have to be
fragmented when going through a VPN. The problem is caused by
fragmentation of these large UDP Kerberos packets. Because UDP is a
connectionless protocol, fragmented UDP packets will be dropped if
they arrive at the destination out of order.

Quoting from
http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx
A common problem is that routers will arbitrarily fragment UDP
packets; when this happens the Kerberos ticket request packets are
discarded by the KDC. 

Please tell me how on earth does the KDC know that the packet has been
fragmented? Packets are fragmented and reassembled on the network
level (IP level), the fragmentation process should be opaque to UDP
and the application, shouldn't it? 

I assume the KDC should just receive data from the socket, no matter
if the datagram was bigger than the MTU, is it correct?

TIA.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/4...@fidonet http://vas.tomsk.ru/

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Is there a way to store "user data" along with principals?

[Mikhail T.]

Hello!

I need to write a utility, that will perform certain tasks on an outside 
web-site (via SOAP). The utility needs to authenticate itself to the 
site every time it runs with a username and password.

Different users (far from all!) ought to be able to run the utility on 
our servers and they should not have direct access to those credentials 
themselves.

We use Kerberos here -- it is the only service that's universally 
reachable throughout our network.

This got me thinking -- can we store these outside credentials as some 
sort of user-data attached to the principals of the people authorized to 
run the utility? Is there a way to associate data with the principals, 
that's meaningless to Kerberos itself, but which would be provided 
verbatim, whenever the successful authentication takes place?

Thanks! Yours,

-mi


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

jgss constraint delegation

[tre]

hello all.
does someone know if the java gss kerberos implementation support 
constrained delegation or if it is planned?

thank you

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos