Re: Canonicalize on Mac

[Tim Alsop]

Rick,

>Have you tried using kinit without --canonicalize against AD, while
>playing around with the case?
Yes, kinit NAME results in NAME@REALM principal in cache. kinit name results in 
name@REALM. This is what I am trying to avoid since I want a consistent 
principal name using the case of the principal defined in AD.

>Have you checked the ticket names in Keychain Access, menu item Ticket
>Viewer?  It may have been setup with your logon name or such, in
>different case, and accepted as such by AD.
This is same as using klist from Terminal which I have been using so I haven’t 
bothered with Ticket Viewer as it has no advantage compared to using klist to 
check case of principal.

>I have no idea what you are asking here.  FWIW, I suspect the Mac
>invokes Heimdal kinit with the desktop logon password.   Check for
>pam_krb5 in your /etc/pam.d/
Yes, pam_krb5 is being used but I don’t know how to configure pam_krb5 so that 
it sends the canonical flag in the as-req so that AD will issue TGT with 
correct case. I don’t think that pam_krb5.so is calling the kinit binary. I 
assume it is using the Heimdal API to authenticate and is not aware of the 
canonical option/flag and hence not configurable.

>Try the suggestions above first, they're a better way to get it going.
>Rather than "making it work" you'll be asking the proper question.  I
>hope -- I don't use AD.
I know I can create the user in Mac with same case as in AD and this will solve 
the issue but often the AD admin who creates the user in AD doesn’t use same 
case.




Tim Alsop
Director
[Telephone] +44 1256 330596

[CyberSafe]<https://CyberSafe.com>

[Web] https://CyberSafe.com/SAP<https://CyberSafe.com/SAP>

Copyright © 2002–2016 CyberSafe Limited. All Rights Reserved. Abbey House, 450 
Bath Road, Longford, Middlesex, UB7 0EB, United Kingdom. Registered in England 
and Wales. Company Number 03245350. VAT Registration Number GB 695 7551 78.

Telephone: +44 203 510 6333 (United Kingdom) | +1 929 333 4499 (United States)


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

Canonicalize on Mac

[Tim Alsop]

Hi

I am using Active Directory as a KDC and using a Mac with OSX 10.8, 10.9, 10.10 
and 10.11

When I configure Kerberos on a Mac OSX system, and login to the Mac and then 
run klist I see a principal name which is lower case but in AD the principal 
name is mixed case.
I can run kinit --canonicalize  and this returns the correct case 
principal, but when I logon to the Mac this is not happening. I assume that an 
API call is being made during Mac logon and not kinit being run. Is this a 
correct assumption ?

I also checked in krb5.conf but there doesn’t appear to be a documented way to 
force the canonical flag on an AS-REQ when Mac login uses Kerberos.

Thanks
Tim
Tim Alsop
Director
[Telephone] +44 1256 330596

[CyberSafe]<https://CyberSafe.com>

[Web] https://CyberSafe.com/SAP<https://CyberSafe.com/SAP>

Copyright © 2002–2016 CyberSafe Limited. All Rights Reserved. Abbey House, 450 
Bath Road, Longford, Middlesex, UB7 0EB, United Kingdom. Registered in England 
and Wales. Company Number 03245350. VAT Registration Number GB 695 7551 78.

Telephone: +44 203 510 6333 (United Kingdom) | +1 929 333 4499 (United States)


Disclaimer: This email message and any attachments transmitted with it may 
contain legally privileged and confidential information and information 
protected by intellectual property rights, and is intended solely for use by 
the above named recipient(s). If you are not the recipient(s) named above, or 
an authorised agent acting on behalf of the recipient(s) named above, you are 
hereby notified that any reading, dissemination, distribution, copying, or 
other use of this message or its attachment(s) is strictly prohibited. If you 
have received this message in error, please notify the sender immediately by 
telephone or by email, and delete this message and all copies and backups 
thereof. No waiver of privilege or confidentiality should be inferred from an 
error in sending.

This email message does not under any circumstances constitute a binding 
commitment by or on behalf of CyberSafe Limited, or any affiliated companies, 
unless it contains an express statement to the contrary from an authorised 
representative and clearly identifies the entity for which the commitment is 
taken.

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

Re: API cache on Mac OSX

[Tim Alsop]

Ok, thanks



-Original Message-
From:  on behalf of Brandon Allbery
Date: Wednesday, 23 September 2015 14:59
To: "kerberos@mit.edu"
Subject: Re: API cache on Mac OSX

On Wed, 2015-09-23 at 13:44 +, Tim Alsop wrote:
> Does anybody know how the API: cache on Mac OS X 10.10 works.
> Is it stored in memory, and is there a daemon that owns the memory
> allocated for credentials caches ?
> Also, is it working same as the API cache in MIT and/or Heimdal code ?

Apple's API: cache is Heimdal's kcm daemon, which recent (1.13+) MIT
supports as the KCM: ccache type.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix openafs kerberos infrastructure xmonadhttp://sinenomine.net


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

API cache on Mac OSX

[Tim Alsop]

Hello

Does anybody know how the API: cache on Mac OS X 10.10 works.
Is it stored in memory, and is there a daemon that owns the memory allocated 
for credentials caches ?
Also, is it working same as the API cache in MIT and/or Heimdal code ?

Thanks

Tim Alsop
Director
[Telephone] +44 1256 330596

[CyberSafe]<https://CyberSafe.com>

[Web] https://CyberSafe.com/SAP<https://CyberSafe.com/SAP>

Copyright © 2002–2015 CyberSafe Limited. All Rights Reserved.
Headquarters: CyberSafe Limited. Abbey House, 450 Bath Road, Longford, 
Middlesex, UB7 0EB, United Kingdom.
Registered in England and Wales. Company Number 03245350. VAT Registration 
Number GB 695 7551 78.


Disclaimer: This email message and any attachments transmitted with it may 
contain legally privileged and confidential information and information 
protected by intellectual property rights, and is intended solely for use by 
the above named recipient(s). If you are not the recipient(s) named above, or 
an authorised agent acting on behalf of the recipient(s) named above, you are 
hereby notified that any reading, dissemination, distribution, copying, or 
other use of this message or its attachment(s) is strictly prohibited. If you 
have received this message in error, please notify the sender immediately by 
telephone or by email, and delete this message and all copies and backups 
thereof. No waiver of privilege or confidentiality should be inferred from an 
error in sending.

This email message does not under any circumstances constitute a binding 
commitment by or on behalf of CyberSafe Limited, CyberSafe North America, or 
any affiliated companies, unless it contains an express statement to the 
contrary from an authorised representative and clearly identifies the entity 
for which the commitment is taken.

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

RE: SAP SSO Setup on UNIX Solaris and Linux [Public]

[Tim Alsop]

Or maybe you can take a look at http://sap.cybersafe.com

Thanks,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
Sylvain Cortes
Sent: 26 July 2012 18:07
To: Sekhar kota; kerberos@mit.edu
Subject: RE: SAP SSO Setup on UNIX Solaris and Linux [Public]

Hi,

Perharps you may have a look at http://www.centrify.com/directcontrol/sap.asp
If you have to manage some "heavy SAP client" on the desktop, they have a good 
solution to provide the Kerberos ticket both on the server and desktop side.

Regards

sylvain




-
Sylvain Cortes - CERBERIS
Partnership & Alliances Manager
Tel: +33 4 76 21 17 03
Fax: +33 4 76 84 68 10
Email: s.cor...@cerberis.com
CERBERIS  http://www.cerberis.com
30 cours libération
38100 Grenoble
France
-

-Message d'origine-
De : kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] De la part de 
Sekhar kota Envoyé : jeudi 26 juillet 2012 10:18 À : kerberos@mit.edu Objet : 
SAP SSO Setup on UNIX Solaris and Linux

Hi,



We are planning to configure SAP SSO (Kerberos) on UNIX servers. All SAP 
Servers are running on Solaris and Linux. Can you please provide the 
architecture, procedure and process we need to follow to setup this ? So that I 
will discuss with customer.



Please share links for reference as well. I appreciate your help if you could 
send ASAP.



Best Regards,

Sekhar Kota
Sr SAP Basis & Netweaver Consultant




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



--

CronLab scanned this message. We don't think it was spam. If it was, please 
report by copying this link into your browser: 
https://swe02.antispam.cronlab.com/mail/index.php?id=043A625D861D.A097B-&learn=spam&host=212.91.130.18


Ce message a été classé Publique par /O=CERB2010/OU=EXCHANGE ADMINISTRATIVE 
GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=SYLVAIN CORTES le jeudi 26 juillet 
2012.
Les labels de classification ont été ajoutés par Titus Message Classification.

 
 
--
This message has been scanned for viruses and dangerous content by CronLab 
(www.cronlab.com), and is believed to be clean.



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: credentials cache type KRB5_FCC_FVNO_4

[Tim Alsop]

Hi,

Does anybody have any information which would help us with the question
below ?
We are trying to understand why the time offset is stored in cache header
when cache type 4 is used.

Thanks,
Tim

On 14/01/2011 06:25, "Srinivas Cheruku"  wrote:

>Hi,
>
> 
>
>>From code I found that, when a TGT is fetched from KDC, the cache header
>stores times_offset based on the authtime of the ticket. Looks like you
>can
>also store usec_offset in the cache header. But I haven't seen any code
>setting the same.
>
> 
>
>Can anyone help me to understand
>
>1.   Why this header is needed ?
>
>2.   When the values times_offset and usec_offset are set?
>
>3.   When the values set in header are used?
>
> 
>
>Thanks,
>Srini
>
>___
>krbdev mailing list krb...@mit.edu
>https://mailman.mit.edu/mailman/listinfo/krbdev



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

RE: Microsoft Active Directory / PKINIT

[Tim Alsop]

Doug,

This is good information. No, we haven't looked at the KILE document, so 
thankyou for reminding us of this.

It looks like wireshark needs to be updated :-)

Take care,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
Douglas E. Engert
Sent: 12 August 2010 20:36
To: kerberos@mit.edu
Subject: Re: Microsoft Active Directory / PKINIT



On 8/12/2010 6:26 AM, Tim Alsop wrote:
> Hi,
>
> Does anybody know if/when Microsoft Active Directory will support PKINIT (RFC 
> 4556). I understand that all versions of MS AD supports draft-9 of PKINIT, 
> but not sure if the RFC is implemented/supported ?
>
> Also, I am interested to know about interoperability between the draft-9 
> implementation and the RFC 4556 implementation. For example, does the PKINIT 
> included in the MIT code, which is RFC compliant interoperate with MS AD 
> (draft-9) ?
>
> Any info you have on this is appreciated.


Have you looked at the Microsoft KILE document? It does list RFC 4556 and 
PA-PK-AS-REP [17] and refers to PA-PK-AS-REP_OLD (15)

http://msdn.microsoft.com/en-us/library/cc233964(v=PROT.13).aspx

In the KRB5-ERROR e-data, padata, I see what Wireshark refers to as 
PA-PK-AS-REP (15), but not 17.

We have mixed 2008 and 2003 DC so for backwards compatibility it might only 
present PA-PK-AS-REP (17) only if all the servers are 2008.

>
> Thanks,
> Tim
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

-- 

  Douglas E. Engert  
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

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: Microsoft Active Directory / PKINIT

[Tim Alsop]

Greg,

Thankyou. I hoped this was the case, but wasn't sure.

Regards,
Tim

-Original Message-
From: Greg Hudson [mailto:ghud...@mit.edu] 
Sent: 12 August 2010 20:15
To: Tim Alsop
Cc: kerberos@mit.edu
Subject: Re: Microsoft Active Directory / PKINIT

On Thu, 2010-08-12 at 07:26 -0400, Tim Alsop wrote:
> Also, I am interested to know about interoperability between the
> draft-9 implementation and the RFC 4556 implementation. For example, 
> does the PKINIT included in the MIT code, which is RFC compliant 
> interoperate with MS AD (draft-9) ?

The PKINIT code in MIT krb5 attempts to interoperate with MS AD, and to the 
best of my knowledge does so, although we don't regularly test that scenario.

(That's the result of a lot of deliberate code, though; draft-9 and the RFC 
implementation are not interoperable, and I believe they use different preauth 
codes as a result of there being draft-9 implementations in the field.)




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

Microsoft Active Directory / PKINIT

[Tim Alsop]

Hi,

Does anybody know if/when Microsoft Active Directory will support PKINIT (RFC 
4556). I understand that all versions of MS AD supports draft-9 of PKINIT, but 
not sure if the RFC is implemented/supported ?

Also, I am interested to know about interoperability between the draft-9 
implementation and the RFC 4556 implementation. For example, does the PKINIT 
included in the MIT code, which is RFC compliant interoperate with MS AD 
(draft-9) ?

Any info you have on this is appreciated.

Thanks,
Tim

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

RE: Kerberos Rant

[Tim Alsop]

Tom,

Yes, the PAC data is required for authorisation purposes.

Yes, there has been some work to make a replacement for Active Directory, that 
issues PAC data in tickets etc. This was developed by a company known as PADL 
(www.padl.com<http://www.padl.com>). They developed the product as open source 
and then sold it to Novell, and Novell have now added to their own product so 
that Novell Netware customers can use Windows clients to logon to Netware 
running on Linux. I am not aware of anybody else who has done the same, but we 
do plan to do it at some time in the future, as we feel there is a big market 
for Active Directory on UNIX or Linux.

Most people today use a KDC on UNIX and use ksetup on workstation, so that 
users password is maintained in the non AD kdc, but have AD for the computer 
account and PAC data.

Thanks,
Tim

From: Tom Medhurst [mailto:tom.medhu...@googlemail.com]
Sent: 07 April 2010 09:35
To: Tim Alsop
Cc: kerberos@mit.edu
Subject: Re: Kerberos Rant

Hi Tim,

No I wasn't aware of that That sucks!
I guess Kerberos is no good for what I need then. Damn.

Now the AD protocol is open; are there any plans to implement this into 
Kerberos so it can be used without AD?

I'm not sure I would need Kerberos if I had a AD running my domain.
Thanks,
Tom
On Wed, Apr 7, 2010 at 8:53 AM, Tim Alsop 
mailto:tim.al...@cybersafe.com>> wrote:
Tom,
I hope you are aware of the PAC data in the Kerberos tickets issued by MS AD, 
and because of this requirement for Windows login, the Active Directory domain 
still needs to be involved, even if user is logging into Windows using a non 
Active Directory KDC (e.g. MIT on UNIX). Basically you just need to run ksetup 
on workstation to configure the non AD realm, then setup trust between AD and 
the non AD realm and you can login from Windows 7 clients.

Thanks,
Tim Alsop
CyberSafe

-Original Message-
From: kerberos-boun...@mit.edu<mailto:kerberos-boun...@mit.edu> 
[mailto:kerberos-boun...@mit.edu<mailto:kerberos-boun...@mit.edu>] On Behalf Of 
Tom Medhurst
Sent: 07 April 2010 08:45
To: kerberos@mit.edu<mailto:kerberos@mit.edu>
Subject: Kerberos Rant

Hi There,
I apologise in advance for the following rant, but I believe there are issues 
that need addressing...

I am completely unable to get Windows clients authenticating against Kerberos 5 
server. I truly appreciate the assistance that Douglas has given me with that 
case, but we have been unsuccessful in getting it to work.

In-fact there are forum posts all over the web, full of people who are unable 
to get Windows clients authenticating against krb5, all that I have encountered 
have been left unanswered.

This message isn't directed in anyway towards Douglas (who says he has been 
using Active Directory for many years now, and no longer uses MIT Kerberos for 
authenticating Windows clients); but it is directed at the Project Managers (if 
there are any?) who have decided that Windows client authentication isn't a 
high enough priority to get working/documented (all documentation on your site 
mentions Windows 2000 and the instructions are no longer valid and things have 
changed in the last 11 years!!).

My complaint is the Kerberos project is all about a security protocol. One 
which can be used to replace the standard user authentication system of the OS. 
Now it doesn't matter how Unix-friendly a company is; at some point in time 
they will want/need to connect a Windows machine to their network (for 
arguments sake, say the bosses new girlfriend has a Windows laptop) and risk 
assessors will think of scenarios like this before using a technology.
If you can't cater for Windows' vast market share; you are no longer a viable 
option!!

The main reason for this rant is because I have seen the amazing code that you 
guys have poured into the project. Plus you've made is open source!
That's absolutely fantastic!! The problem is I have spent weeks trying to get 
this working, and now I basically have something that is worthless. The amount 
of time I've spent on this exceeds the cost of a *Winblows* Server OS which 
ships with Active Directory!

I dislike Windows probably more than the next Unix geek, and this is why I 
chose to write this email rather than just move on to the more obvious 
solution. I really want to use Kerberos as a homogeneous logon service for 
networks I provide to customers, but without Windows support I simply cannot 
and the cost of installing a system for a startup company rises enormously.

I am not going to consider Samba 4 as an alternative as it has been in beta for 
more than 3 years and is not yet fit for enterprise use. Kerberos is!
I plead with anyone who has had Windows 7 authenticating against an MIT 
Kerberos server to please assist me in getting it working. I'd be happy to 
contribute a large document to your web site explaining how we achieved the end 
goal (including 

RE: Kerberos and RSA SecureID

[Tim Alsop]

Tim,
Have you tried visiting http://rsasecured.com and searching for Kerberos ?

Thanks,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
Hartmann, Tim
Sent: 15 March 2010 18:26
To: Kerberos
Subject: Kerberos and RSA SecureID

Hi,

I'm looking to see if I can integrate RSA SecureID tokens to our MIT Kerberos 
infrastructure, and was wondering if anyone had any experience with setting 
that up, or could direct me to any documentation that might be out their!  
Ideally, I'd like to associate a policy with SecureID, so that administrative 
principles and users are required use keyfobs, were as normal users are not. 

If anyone has any thought, I'd be much obliged, I've run into a number of dead 
ends on google :( 


Thanks!

Tim



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


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

RE: Kerberos multi domain - Update

[Tim Alsop]

Flavien,

When you use kinit user_n...@msdemo2 the keytab file is not used, unless you 
use -k option. Without -k a password is used to get the initial ticket, and 
with -k the key in the keytab is used instead of password entered by user.

It looks like there is a bug in the Kerberos library you are using, and it is 
causing this exception.

Thanks,
Tim

-Original Message-
From: BOUCHER, Flavien [mailto:flavien.a.bouc...@sogeti.com] 
Sent: 03 January 2010 10:33
To: Tim Alsop; kerberos@mit.edu
Subject: RE: Kerberos multi domain - Update

Hi Tim,

when I try I obtain this result :

java.lang.ClassCastException: java.lang.NegativeArraySizeException incompatible 
with com.ibm.security.krb5.KrbException
at com.ibm.security.krb5.g.a(g.java:78)
at com.ibm.security.krb5.g.a(g.java:10)
at com.ibm.security.krb5.internal.tools.Kinit.a(Kinit.java:126)
at com.ibm.security.krb5.internal.tools.Kinit.(Kinit.java:65)
at com.ibm.security.krb5.internal.tools.Kinit.main(Kinit.java:150)
com.ibm.security.krb5.KrbException, code état : 0
message : java.lang.ClassCastException: 
java.lang.NegativeArraySizeException incompatible with 
com.ibm.security.krb5.KrbException


Is it an issue with my keytab file ?

Regards.
Flavien.

-Message d'origine-
De : Tim Alsop [mailto:tim.al...@cybersafe.com]
Envoyé : dimanche 3 janvier 2010 11:24
À : BOUCHER, Flavien; kerberos@mit.edu
Objet : RE: Kerberos multi domain - Update

Flavien,

Have you tried:

kinit user_n...@msdemo2

Thanks,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
BOUCHER, Flavien
Sent: 03 January 2010 09:01
To: kerberos@mit.edu
Subject: Re: Kerberos multi domain - Update

Hi,

thaks for your answer Edward. My two KDC have distinct IP @ and port.

I have done a test with KINIT. When I run 'KINIT -A user_name'  , the KINIT 
command build user_n...@msdemo<mailto:user_n...@msdemo>  , MSDEMO is the 
default_realm setup in my krb5.conf. How could I obtain 
user_n...@msdemo2<mailto:user_n...@msdemo2> except by changing default_realm in 
krb5.conf ?

Regards.

Flavien.



Date: Sat, 02 Jan 2010 15:10:56 +1300

From: Edward Murrell 

Subject: Re: Kerberos multi domain

To: "kerberos@mit.edu" 

Message-ID: <1262398256.2052.29.ca...@boyle>

Content-Type: text/plain; charset="UTF-8"

As far as I know, MIT kerberos can run multiple KDC's from the same machine, 
but each realm needs to have it's own IP or set of ports.

On Fri, 2010-01-01 at 13:19 +0100, BOUCHER, Flavien wrote:

> Hi,

>

> I need to setup kerberos for six distinct domain, there is no trust 
> relationship between each domain.

> When I setup one domain by one, it's working.

>

> After testing each domain one by one, I merge the keytab file, and change the 
> krb5.conf file:

>

> [libdefaults]

> default_realm = MSDEMO

> default_keytab_name =
> FILE:C:\Kerberos\lcserver01.keytab

> default_tkt_enctypes = rc4-hmac des-cbc-md5

> default_tgs_enctypes = rc4-hmac des-cbc-md5

> forwardable = true

> renewable = true

> noaddresses = true

> clockskew = 300

> [realms]

> MSDEMO = {

> kdc = dc.msdemo.local:88

> default_domain = dc.msdemo.local

> }

>

> MSDEMO2 = {

> kdc = dc2.msdemo2.local:88

> default_domain = msdemo2.local

> }

> [domain_realm]

> .msdemo.local = MSDEMO

> .msdemo2.local = MSDEMO2

>

>

> When I merge the keytab of this two domains and change the krb5.conf, just 
> the authentication for MSDEMO is working.

> When I change the krb5.conf, and enter default_realm = MSDEMO2, the 
> authentication is working for MSDEMO2.

>

> It's possible to make the authentication works for the both domain in the 
> same time ?

>

> Regards.

>

> Flavien.

>

>

>

> 

> Kerberos mailing list Kerberos@mit.edu

> https://mailman.mit.edu/mailman/listinfo/kerberos



Flavien Boucher / Sogeti / Paris France
Mob. : +33 (0) 6.07.72.60.67
www.sogeti.com<http://www.sogeti.com/>
Email : flavien.a.bouc...@sogeti.com<mailto:flavien.a.bouc...@sogeti.com>
6-8 rue Duret / 75016 Paris
Join the Collaborative Business Experience 

P
Please consider the environment and do not print this email unless absolutely 
necessary. Sogeti encourages environmental awareness.


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


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

RE: Kerberos multi domain - Update

[Tim Alsop]

Flavien,

Have you tried:

kinit user_n...@msdemo2

Thanks,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
BOUCHER, Flavien
Sent: 03 January 2010 09:01
To: kerberos@mit.edu
Subject: Re: Kerberos multi domain - Update

Hi,

thaks for your answer Edward. My two KDC have distinct IP @ and port.

I have done a test with KINIT. When I run 'KINIT -A user_name'  , the KINIT 
command build user_n...@msdemo  , MSDEMO is the 
default_realm setup in my krb5.conf. How could I obtain 
user_n...@msdemo2 except by changing default_realm in 
krb5.conf ?

Regards.

Flavien.



Date: Sat, 02 Jan 2010 15:10:56 +1300

From: Edward Murrell 

Subject: Re: Kerberos multi domain

To: "kerberos@mit.edu" 

Message-ID: <1262398256.2052.29.ca...@boyle>

Content-Type: text/plain; charset="UTF-8"

As far as I know, MIT kerberos can run multiple KDC's from the same machine, 
but each realm needs to have it's own IP or set of ports.

On Fri, 2010-01-01 at 13:19 +0100, BOUCHER, Flavien wrote:

> Hi,

>

> I need to setup kerberos for six distinct domain, there is no trust 
> relationship between each domain.

> When I setup one domain by one, it's working.

>

> After testing each domain one by one, I merge the keytab file, and change the 
> krb5.conf file:

>

> [libdefaults]

> default_realm = MSDEMO

> default_keytab_name = 
> FILE:C:\Kerberos\lcserver01.keytab

> default_tkt_enctypes = rc4-hmac des-cbc-md5

> default_tgs_enctypes = rc4-hmac des-cbc-md5

> forwardable = true

> renewable = true

> noaddresses = true

> clockskew = 300

> [realms]

> MSDEMO = {

> kdc = dc.msdemo.local:88

> default_domain = dc.msdemo.local

> }

>

> MSDEMO2 = {

> kdc = dc2.msdemo2.local:88

> default_domain = msdemo2.local

> }

> [domain_realm]

> .msdemo.local = MSDEMO

> .msdemo2.local = MSDEMO2

>

>

> When I merge the keytab of this two domains and change the krb5.conf, just 
> the authentication for MSDEMO is working.

> When I change the krb5.conf, and enter default_realm = MSDEMO2, the 
> authentication is working for MSDEMO2.

>

> It's possible to make the authentication works for the both domain in the 
> same time ?

>

> Regards.

>

> Flavien.

>

>

>

> 

> Kerberos mailing list Kerberos@mit.edu

> https://mailman.mit.edu/mailman/listinfo/kerberos



Flavien Boucher / Sogeti / Paris France
Mob. : +33 (0) 6.07.72.60.67
www.sogeti.com
Email : flavien.a.bouc...@sogeti.com
6-8 rue Duret / 75016 Paris
Join the Collaborative Business Experience

P
Please consider the environment and do not print this email unless
absolutely necessary. Sogeti encourages environmental awareness.


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: CISCO and kerberos

[Tim Alsop]

Hi,

You can use telnet and only if using DES (etype 1 or 3) or DES3-CBC-MD5 (etype 
5). The code in the cisco IOS is based on CyberSafe code and a very very old 
release of it, so might not work with MS AD, and not with Heimdal code.

Thanks,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
Nikolay Shopik
Sent: 01 September 2009 14:41
To: kerberos@mit.edu
Subject: Re: CISCO and kerberos

On 01.09.2009 14:55, Nikos Nikoleris wrote:
> jarek wrote:
>> Hi all!
>>
>> I'd like to configure CISCO Catalyst to use kerberos against AD server
>> W2008. I'd like to login to cisco using ticket and telnet.krb5 from
>> krb5-clients package. When I'm trying telnet.krb5 -a -f cisco_ip, I'm
>> getting:
>>
>> [ Kerberos V5 refuses authentication ]
>> kerberos_server_auth:Couldn't authenticate client from
>> test-nms.test.local.
>>
>> What can be wrong ?
>>
>> Has someone working example of CISCO config for such scenario ?
>>
>> J.
>
> Hi Jarek,
>
> A cisco working here with kerberos authentication but the kdc is heidmal
> kerberos. Some suggestions are:
> * Timing issues, you have to make sure both the kdc and the cisco are
> sync'd... (That's very important)
> * Try uploading the keytab using only the DES-CBC-CRC enc of the cisco
> principal...
> * Your cisco should have a configuration like:
> aaa new-model
> aaa authentication login default krb5-telnet krb5 local enable
> aaa authorization exec default krb5-instance
> kerberos local-realm YOUR.REALM
> kerberos srvtab entry host/fqdn.of.your.swi...@your.realm (there should
> be some numbers here as well)
> kerberos clients mandatory
> kerberos server YOUR.REALM $(IP of your KDC)
> kerberos instance map admin 15 # this will map kerberos users */admin to
> the superuser of cisco
> kerberos credentials forward # that's optinal
>
> # I strongly suggest this as well adjusted to your case
> ntp server your.ntp.server
> clock timezone GMT -6
> clock summer-time CDT recurring
>
> -- Nikos
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Hi Nikos,

If I'm not mistaken they don't yet support kerberos for SSH aren't they?


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: cross domain Integrated Windows Auth (aka SPNEGO)

[Tim Alsop]

Hello again.

I only received one response to my email below, so I wondered if anybody else 
has any experience of this setup and how I can solve it ?
The response I received mentioned using netdom with /addtln parameter, but this 
will only work when AD and non-AD realm are involved. In our case there is only 
AD being used and not MIT KDC or Heimdal KDC.

Thanks,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
Tim Alsop
Sent: 04 June 2009 20:01
To: kerberos@mit.edu
Subject: cross domain Integrated Windows Auth (aka SPNEGO)

Hi,

One of our customers has a problem with Integrated Windows Authentication in IE 
browser. They have two AD domains which are part of different forests, so 
external trust is used. The workstation is joined to domain1 and user logs onto 
this domain, then opens browser to access web server which is on a server 
joined to domain2. This is not working, but if workstation on domain2 is used 
the logon works fine.

>From wireshark trace on workstation we can see a TGS-REQ being sent to domain1 
>for the HTTP/@ and of course this principal is 
>not found in domain1 so principal not found is returned - the browser then 
>uses NTLM and attempts to authenticate, but the web server we are using does 
>not support NTLM.

Is there any way we can configure workstation so that it knows which domain the 
webserver is in ? We found a section in registry which looks like it might be 
the correct place to configure this, but it didn't help :(

Thanks in advance for your help,

Tim


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

cross domain Integrated Windows Auth (aka SPNEGO)

[Tim Alsop]

Hi,

One of our customers has a problem with Integrated Windows Authentication in IE 
browser. They have two AD domains which are part of different forests, so 
external trust is used. The workstation is joined to domain1 and user logs onto 
this domain, then opens browser to access web server which is on a server 
joined to domain2. This is not working, but if workstation on domain2 is used 
the logon works fine.

>From wireshark trace on workstation we can see a TGS-REQ being sent to domain1 
>for the HTTP/@ and of course this principal is 
>not found in domain1 so principal not found is returned - the browser then 
>uses NTLM and attempts to authenticate, but the web server we are using does 
>not support NTLM.

Is there any way we can configure workstation so that it knows which domain the 
webserver is in ? We found a section in registry which looks like it might be 
the correct place to configure this, but it didn't help :(

Thanks in advance for your help,

Tim


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

RE: Authenticating using lower case domain/realm

[Tim Alsop]

San,

You need an implementation of Kerberos, which has support for UPN 
authentication (using nt-enterprise principal names) and the canonical flag, as 
well as client side realm referrals. I guess the implementation of Kerberos on 
Ubuntu does not have these extensions coded.

I represent a vendor who develops and sells a commercial implementation of 
Kerberos, and our product works as you expect - see below:

tal...@perky:~> kinit talsop
Password for tal...@dev.local:
tal...@perky:~> klist
  Cache Type: Kerberos V5 Credentials Cache
  Cache File: /krb5/tmp/cc/krb5cc_1000
   Cache Version: 0502
   Default Principal: tal...@dev.local

Valid FromExpires   Service Principal
    -
Mon 09 Mar 2009 12:06:03 GMT  Mon 09 Mar 2009 20:06:23 GMT  
krbtgt/dev.lo...@dev.local
tal...@perky:~> kinit tal...@dev.local
Password for tals...@dev.local@DEV.LOCAL:
tal...@perky:~> klist
  Cache Type: Kerberos V5 Credentials Cache
  Cache File: /krb5/tmp/cc/krb5cc_1000
   Cache Version: 0502
   Default Principal: tal...@dev.local

Valid FromExpires   Service Principal
    -
Mon 09 Mar 2009 12:06:16 GMT  Mon 09 Mar 2009 20:06:35 GMT  
krbtgt/dev.lo...@dev.local
tal...@perky:~>

Thanks,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
San tos
Sent: 09 March 2009 11:49
To: kerberos@mit.edu
Subject: Authenticating using lower case domain/realm

Hello to all.

I have successfully configured ubuntu machines to authenticate to a active
directory running windows 2k (pam_krb5/LDAP/Kerberos). The realm is
DOMAIN.COM, however in order to be user friendly and maintain the same login
address in everything, i need to authenticate using u...@domain.com instead
of u...@domain.com.

It seems windows 2k, accepts either way, but maybe kerberos don't like the
response it receives:

kinit(v5): KDC reply did not match expectations while getting initial
credentials



I'm using ubuntu 8.10 and:

krb5-config 1.19 Configuration files for Kerberos Version 5
krb5-user 1.6.dfsg.4~beta1-3 Basic programs to authenticate using MIT Ker
libkrb53 1.6.dfsg.4~beta1-3 MIT Kerberos runtime libraries

The krb5.conf:

[libdefaults]
default_realm = DOMAIN.COM
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
#   dns_lookup_realm = true
#   dns_lookup_kdc = false

[realms]
DOMAIN.COM = {
kdc = dc.domain.com
admin_server = dc.domain.com
default_domain = DOMAIN.COM
}


[domain_realm]
domain.com = DOMAIN.COM
.domain.com  = DOMAIN.COM



I have googled, read the mans, tried a lot of other configurations, etc, for
days now, but can't figure it out. I will appreciate any input you got on
this.


Thanks in advance for you replies.

Santos

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: computer account change password with Windows 2008 domain

[Tim Alsop]

Michael,

I have just been reminded/corrected that our product actually uses kpasswd 
protocol to change password, not ldap change password - sorry for any confusion 
caused by this mistake. This is perhaps why it works for us, but not for you. 
Maybe you could also use kpasswd ?

Anyway, perhaps the info in my last post helps and this is related to a domain 
policy setting in some way ?

Good luck,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
Tim Alsop
Sent: 07 January 2009 15:20
To: Michael Engemann; kerberos@mit.edu
Subject: RE: computer account change password with Windows 2008 domain

Michael,

I don't know what is wrong, but I do know that our product works fine with 
Windows Server 2008 and 2003. We use our own Kerberos and GSS-API library (not 
MIT or Heimdal), and Cyrus SASL with OpenLDAP.

We have seen a similar problem where Active Directory on Windows Server 2003 
has the LDAP Server signing policy set in the domain controllers group policy. 
This setting means that AD expects SSL/TLS to be used for signing, but when 
Kerberos/GSS/SASL/LDAP is used the signing is done using Kerberos keys instead. 
It seems that MS AD has a bug which effects use of SASL/LDAP bind when this 
policy setting is made. This is a discussed at 
http://technet2.microsoft.com/windowsserver/en/library/56044016-3123-4859-8fd9-c5a461a1c5c81033.mspx?mfr=true
 and I have included some output below which was shown when this policy setting 
is made. Not sure if this helps at all ? Perhaps your Win2k8 domain has a 
policy setting which is non-default and is causing your issue due to a similar 
bug ?

SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Strong(er) authentication required (8)
additional info: 2028: LdapErr: DSID-0C09018A, comment: The server 
requires binds to turn on integrity checking if SSL\TLS are not already active 
on the connection, data 0, vece
Failed to connect to LDAP Server
Error occurred in netjoin while performing netjoin operations ( 0x5102 
20738 )
Cannot open connection to LDAP Server

Thanks,
Tim

-Original Message-
From: Michael Engemann [mailto:enge...@uni-muenster.de]
Sent: 07 January 2009 15:10
To: Tim Alsop; Michael Engemann; kerberos@mit.edu
Subject: AW: computer account change password with Windows 2008 domain

Hi Tim,

can you tell me than what am I doing wrong?
Even a simple ldapsearch that was functioning for Windows 2003 throws an error 
for 2008:


ldapsearch -Hldap://fqdn -b "" -s base -Omaxssf=0 -ZZ
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: 2029: LdapErr: DSID-0C09048A, comment: Cannot bind 
using sign/seal on a connection on which TLS or SSL is in effect, data 0, v1771

Thanks,

Michael


> -Ursprüngliche Nachricht-
> Von: Tim Alsop [mailto:tim.al...@cybersafe.com]
> Gesendet: Mittwoch, 7. Januar 2009 15:57
> An: Michael Engemann; kerberos@mit.edu
> Betreff: RE: computer account change password with Windows 2008 domain
>
> Hi,
>
> We are able to change/set passwords using Kerberos/GSS-API/SASL/LDAP
> when using Active Directory on Windows Server 2008.
>
> Thanks,
> Tim
>
> -Original Message-
> From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On
> Behalf Of Michael Engemann
> Sent: 07 January 2009 14:46
> To: kerberos@mit.edu
> Subject: computer account change password with Windows 2008 domain
>
> Hi,
>
> we are also experiencing the bug in Windows Server 2008 that was
> mentionend on this list in April 2008 by Russ Allberry:
>
> * Microsoft broke password changes via the LDAP protocol with SASL
> GSSAPI
>   binds in Windows 2008.  In Windows 2003, provided that you didn't try
> to
>   negotiate an SASL privacy layer, you could connect via TLS and
>   authenticate with GSSAPI and query or set the password attribute
>   directly.  In Windows 2008, this no longer works; you always get the
>   error from the server that you are not permitted to negotiate a
> privacy
>   layer when using TLS, even though you're not trying to.  We've
> already
>   filed this as a bug.
>
> Are there probably any news about a fix or a known workaround?
>
> Thanks in advance,
>
> Michael
>
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos


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


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

RE: computer account change password with Windows 2008 domain

[Tim Alsop]

Michael,

I don't know what is wrong, but I do know that our product works fine with 
Windows Server 2008 and 2003. We use our own Kerberos and GSS-API library (not 
MIT or Heimdal), and Cyrus SASL with OpenLDAP.

We have seen a similar problem where Active Directory on Windows Server 2003 
has the LDAP Server signing policy set in the domain controllers group policy. 
This setting means that AD expects SSL/TLS to be used for signing, but when 
Kerberos/GSS/SASL/LDAP is used the signing is done using Kerberos keys instead. 
It seems that MS AD has a bug which effects use of SASL/LDAP bind when this 
policy setting is made. This is a discussed at 
http://technet2.microsoft.com/windowsserver/en/library/56044016-3123-4859-8fd9-c5a461a1c5c81033.mspx?mfr=true
 and I have included some output below which was shown when this policy setting 
is made. Not sure if this helps at all ? Perhaps your Win2k8 domain has a 
policy setting which is non-default and is causing your issue due to a similar 
bug ?

SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Strong(er) authentication required (8)
additional info: 2028: LdapErr: DSID-0C09018A, comment: The server 
requires binds to turn on integrity checking if SSL\TLS are not already active 
on the connection, data 0, vece
Failed to connect to LDAP Server
Error occurred in netjoin while performing netjoin operations ( 0x5102 
20738 )
Cannot open connection to LDAP Server

Thanks,
Tim

-Original Message-
From: Michael Engemann [mailto:enge...@uni-muenster.de]
Sent: 07 January 2009 15:10
To: Tim Alsop; Michael Engemann; kerberos@mit.edu
Subject: AW: computer account change password with Windows 2008 domain

Hi Tim,

can you tell me than what am I doing wrong?
Even a simple ldapsearch that was functioning for Windows 2003 throws an error 
for 2008:


ldapsearch -Hldap://fqdn -b "" -s base -Omaxssf=0 -ZZ
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: 2029: LdapErr: DSID-0C09048A, comment: Cannot bind 
using sign/seal on a connection on which TLS or SSL is in effect, data 0, v1771

Thanks,

Michael


> -Ursprüngliche Nachricht-
> Von: Tim Alsop [mailto:tim.al...@cybersafe.com]
> Gesendet: Mittwoch, 7. Januar 2009 15:57
> An: Michael Engemann; kerberos@mit.edu
> Betreff: RE: computer account change password with Windows 2008 domain
>
> Hi,
>
> We are able to change/set passwords using Kerberos/GSS-API/SASL/LDAP
> when using Active Directory on Windows Server 2008.
>
> Thanks,
> Tim
>
> -Original Message-
> From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On
> Behalf Of Michael Engemann
> Sent: 07 January 2009 14:46
> To: kerberos@mit.edu
> Subject: computer account change password with Windows 2008 domain
>
> Hi,
>
> we are also experiencing the bug in Windows Server 2008 that was
> mentionend on this list in April 2008 by Russ Allberry:
>
> * Microsoft broke password changes via the LDAP protocol with SASL
> GSSAPI
>   binds in Windows 2008.  In Windows 2003, provided that you didn't try
> to
>   negotiate an SASL privacy layer, you could connect via TLS and
>   authenticate with GSSAPI and query or set the password attribute
>   directly.  In Windows 2008, this no longer works; you always get the
>   error from the server that you are not permitted to negotiate a
> privacy
>   layer when using TLS, even though you're not trying to.  We've
> already
>   filed this as a bug.
>
> Are there probably any news about a fix or a known workaround?
>
> Thanks in advance,
>
> Michael
>
> 
> 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: computer account change password with Windows 2008 domain

[Tim Alsop]

Hi,

We are able to change/set passwords using Kerberos/GSS-API/SASL/LDAP when using 
Active Directory on Windows Server 2008.

Thanks,
Tim

-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of 
Michael Engemann
Sent: 07 January 2009 14:46
To: kerberos@mit.edu
Subject: computer account change password with Windows 2008 domain

Hi,

we are also experiencing the bug in Windows Server 2008 that was mentionend on 
this list in April 2008 by Russ Allberry:

* Microsoft broke password changes via the LDAP protocol with SASL GSSAPI
  binds in Windows 2008.  In Windows 2003, provided that you didn't try to
  negotiate an SASL privacy layer, you could connect via TLS and
  authenticate with GSSAPI and query or set the password attribute
  directly.  In Windows 2008, this no longer works; you always get the
  error from the server that you are not permitted to negotiate a privacy
  layer when using TLS, even though you're not trying to.  We've already
  filed this as a bug.

Are there probably any news about a fix or a known workaround?

Thanks in advance,

Michael


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: Trouble with service principal missing its realm

[Tim Alsop]

Jeffrey,

Regarding:

> A service ticket in the credential cache without a realm name
> is a service ticket that was obtained using server side referrals.
> The actual realm name was not specified by the client when
> requesting the service ticket.

[Tim Alsop] Is the fact that there is no realm, a bug, or is the cache supposed 
to contain tickets without a realm in this scenario ? Surely if actual realm 
was not specified, when the actual realm is determined by KDC, and ticket 
issued, this realm should be used when putting the ticket in the client cache ? 
if not, why not ?

Thanks,
Tim


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

RE: Regarding algorithm support

[Tim Alsop]

Naveen,

This cipher suite is available (etype = 5) and supported in CyberSafe 
TrustBroker client libraries, and I don't believe it is included in MIT 
distribution.
My understanding is that MIT 3DES implementation is etype = 7 (DES-CBC-SHA1).

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of naveen.bn
Sent: 15 July 2008 15:15
To: kevin
Cc: kerberos@mit.edu
Subject: Regarding algorithm support

Hi Kevin,
I felt the krb5-1.6.3 does not supports des3_cbc_md5.  My client application 
requires des3_cbc_md5 support from
the kdc.  Can you please guide on giving kdc server support for des3_cbc_md5 
algorithm.

Thank you

with regards
naveen





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: Hotfix released for Windows Server 2008 KDC issue

[Tim Alsop]

Ross,

There is a mistake in the kb in the "File information" section, where it
suggests that Windows Server 2003, x86-based files are changed. I think
this should refer to Windows Server 2008 since this is what the fix is
for. There is no need for this fix if Windows Server 2003 is used.

Also, there doesn't appear to be any x64 hotfix available for download.

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Wilper, Ross A
Sent: 13 May 2008 17:46
To: kerberos@mit.edu
Subject: Hotfix released for Windows Server 2008 KDC issue

The hotfix for my KDC issue has been publicly released.

 

http://support.microsoft.com/kb/951191

 

-Ross

 

> * Authentication to Active Directory using a principal that contains a

>   slash (such as service/foo) from a keytab generated by the Windows 

> tool is broken in Windows 2008.  


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: advice on kerberizing products

[Tim Alsop]

Ken wrote:

> You've discovered an unfortunate truth - it's difficult to ship a
> third-party application that links against Kerberos libraries and
> expect it to be portable.  And since the Heimdal and MIT Kerberos
> libraries aren't API compatible, you either have to pick one or the
> other, or port to both (in my experience, porting to both isn't hard,
> it's just annoying).

It is also worth mentioning that GSS-API is closer to being portable
than
native Kerberos APIs, and you should use GSS as much as possible to
avoid
some interoperability issues. It also makes your coding a lot easier.

> More and more operating systems are shipping with Kerberos libraries,
but
> they're not universal just yet.  I can only offer suggestions based on
what
> I have seen other vendors do in your position:

> 1) Dynamically load all Kerberos functions at runtime with dlopen() or
>the equivalent.

> 2) Encapsulate all of your Kerberos functionality into an open-source
>module or program and have your customers compile that particular
bit
>themselves.

> 3) Include with your product a complete copy of whatever Kerberos
>implementation you prefer.

4) Since your company is developing and selling commercial products to 
   customers and providing support service that the customer expects for
   such products, perhaps you could partner with a vendor who provides 
   a cross platform Kerberos implementation, so you get a consistent and
   supported solution, for any operating system your product may run on.

   Also, your customers get a complete solution that is fully supported 
   by yourself and the partner company. I represent one such company, 
   namely "CyberSafe". 

> From the customer's perspective, 1) is easier.  2) is easier for you,
> as it pushes some of the issues back onto the customer, but it might
> present some interesting support challenges.  I don't recommend 3);
I'm
> only including it for the sake of completeness.

I don't recommend option 3 either, but there are companies that have
chosen this 
path, e.g. Oracle. Instead, I recommend you look at option 4.

Thanks,
Tim



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

RE: computer account change password with Windows 2008 domain

[Tim Alsop]

Julio,

 

The recommended procedure is for you to contact your local Microsoft
support, and ask them if they can provide you with the hotfix.

 

Regards,

Tim

 

From: Julio Cesar Parra/Mexico/IBM [mailto:[EMAIL PROTECTED] 
Sent: 02 April 2008 00:15
To: Wilper, Ross A; Russ Allbery
Cc: kerberos@mit.edu; [EMAIL PROTECTED]; Tim Alsop; Srinivas
Cheruku
Subject: RE: computer account change password with Windows 2008 domain

 


Hello , I'm interested in the hotfix too, I have the same problem
recognizing the service principals configuring a System i to use
kerberos, Could you please let me know how to get the hotfix to test it
? 

Regards. 
Julio. 




"Tim Alsop" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED] 

01/04/2008 16:02 

To

"Wilper, Ross A" <[EMAIL PROTECTED]>, "Russ Allbery"
<[EMAIL PROTECTED]> 

cc

Srinivas Cheruku <[EMAIL PROTECTED]>, kerberos@mit.edu 

Subject

RE: computer account change password with Windows 2008 domain

 






Ross,

Thankyou. If a hotfix is available, our partner support people at MS
will be able to get us same hotfix to test.

Regards,
Tim

-Original Message-
From: Wilper, Ross A [mailto:[EMAIL PROTECTED] 
Sent: 01 April 2008 22:44
To: Russ Allbery; Tim Alsop
Cc: kerberos@mit.edu; Srinivas Cheruku
Subject: RE: computer account change password with Windows 2008 domain

Our case SRZ080225000456 is open for the Windows 2008 KDC being unable
to authenticate any account with a "/" in the principal name. On this
case, we have been issued a private hotfix that appears to resolve the
issue. The hotfix is now in review for public release.

Our case SRZ080306000400 is open for the Windows 2008 LDAP server not
being able to negotiate QOP for SASL binds over SSL with OpenLDAP. This
case is still in the troubleshooting phase.

-Ross

-Original Message-
From: Russ Allbery [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 01, 2008 2:36 PM
To: Tim Alsop
Cc: kerberos@mit.edu; Srinivas Cheruku; Wilper, Ross A
Subject: Re: computer account change password with Windows 2008 domain

Ross, could you give Tim our reference numbers for our Microsoft bug
reports that we filed as part of Guest?  They're running into one of the
same issues, and I figure the more the merrier on the complaining.

"Tim Alsop" <[EMAIL PROTECTED]> writes:

> Russ,
>
> That's great information, thanks.
>
> We are using Kerberos set password protocol to change/set the computer
> account password, but since the SPN used contains a / I suspect we are
> experiencing the same issues you described.
>
> If you have any reference numbers for your problems, then I would like
> to mention them to MS when I talk to them tomorrow. 
>
> Thanks,
> Tim
>
> -Original Message-
> From: Russ Allbery [mailto:[EMAIL PROTECTED] 
> Sent: 01 April 2008 22:17
> To: Tim Alsop
> Cc: kerberos@mit.edu
> Subject: Re: computer account change password with Windows 2008 domain
>
> "Tim Alsop" <[EMAIL PROTECTED]> writes:
>
>> We have discovered a problem when we try to set/change password for a
>> computer account in AD on Windows Server 2008. The computer account
is
>> created so we can use it for a service/application, and the key is
>> created from it's password (randomly generated) and extracted into a
> key
>> table file.
>>
>> Our code is able to create the account (authenticating to AD using
>> SASL/GSS/Kerberos) but when we try and set the computer account's
>> password to a random value, the request is rejected, so it looks like
> AD
>> on Windows 2008 has some changes which stop password changes for
>> computer accounts, or maybe something which is stopping changes to
>> passwords for accounts that use a principal name such as
>> name/[EMAIL PROTECTED]
>
> You don't say here *how* you're changing the password, but there are
two
> Active Directory bugs in Windows 2008 that you may be running into:
>
> * Authentication to Active Directory using a principal that contains a
>   slash (such as service/foo) from a keytab generated by the Windows
> tool
>   is broken in Windows 2008.  It works fine if there is no slash in
the
>   principal.  Microsoft has identified this as a bug and is working on
a
>   fix.
>
> * Microsoft broke password changes via the LDAP protocol with SASL
> GSSAPI
>   binds in Windows 2008.  In Windows 2003, provided that you didn't
try
> to
>   negotiate an SASL privacy layer, you could connect via TLS and
>   authenticate with GSSAPI and query or set the password attribute
>   directly.  In Windows 2008, this no longer works; you always get the
>   error from the server that you are not permitted to negotiate a
> privacy
>   layer when usi

RE: computer account change password with Windows 2008 domain

[Tim Alsop]

Doug,

Yes, msktutil will likely fail due to same reasons.

Regards,
Tim

-Original Message-
From: Douglas E. Engert [mailto:[EMAIL PROTECTED] 
Sent: 01 April 2008 22:44
To: Russ Allbery
Cc: Tim Alsop; Srinivas Cheruku; [EMAIL PROTECTED]; kerberos@mit.edu
Subject: Re: computer account change password with Windows 2008 domain

We use msktuil, and I believe it will have the same problem.
Add our name to the list too!


Russ Allbery wrote:
> Ross, could you give Tim our reference numbers for our Microsoft bug
> reports that we filed as part of Guest?  They're running into one of
the
> same issues, and I figure the more the merrier on the complaining.
> 
> "Tim Alsop" <[EMAIL PROTECTED]> writes:
> 
>> Russ,
>>
>> That's great information, thanks.
>>
>> We are using Kerberos set password protocol to change/set the
computer
>> account password, but since the SPN used contains a / I suspect we
are
>> experiencing the same issues you described.
>>
>> If you have any reference numbers for your problems, then I would
like
>> to mention them to MS when I talk to them tomorrow. 
>>
>> Thanks,
>> Tim
>>
>> -Original Message-
>> From: Russ Allbery [mailto:[EMAIL PROTECTED] 
>> Sent: 01 April 2008 22:17
>> To: Tim Alsop
>> Cc: kerberos@mit.edu
>> Subject: Re: computer account change password with Windows 2008
domain
>>
>> "Tim Alsop" <[EMAIL PROTECTED]> writes:
>>
>>> We have discovered a problem when we try to set/change password for
a
>>> computer account in AD on Windows Server 2008. The computer account
is
>>> created so we can use it for a service/application, and the key is
>>> created from it's password (randomly generated) and extracted into a
>> key
>>> table file.
>>>
>>> Our code is able to create the account (authenticating to AD using
>>> SASL/GSS/Kerberos) but when we try and set the computer account's
>>> password to a random value, the request is rejected, so it looks
like
>> AD
>>> on Windows 2008 has some changes which stop password changes for
>>> computer accounts, or maybe something which is stopping changes to
>>> passwords for accounts that use a principal name such as
>>> name/[EMAIL PROTECTED]
>> You don't say here *how* you're changing the password, but there are
two
>> Active Directory bugs in Windows 2008 that you may be running into:
>>
>> * Authentication to Active Directory using a principal that contains
a
>>   slash (such as service/foo) from a keytab generated by the Windows
>> tool
>>   is broken in Windows 2008.  It works fine if there is no slash in
the
>>   principal.  Microsoft has identified this as a bug and is working
on a
>>   fix.
>>
>> * Microsoft broke password changes via the LDAP protocol with SASL
>> GSSAPI
>>   binds in Windows 2008.  In Windows 2003, provided that you didn't
try
>> to
>>   negotiate an SASL privacy layer, you could connect via TLS and
>>   authenticate with GSSAPI and query or set the password attribute
>>   directly.  In Windows 2008, this no longer works; you always get
the
>>   error from the server that you are not permitted to negotiate a
>> privacy
>>   layer when using TLS, even though you're not trying to.  We've
already
>>   filed this as a bug.
>>
>> In both cases, if you have a support contract with Microsoft and this
is
>> a
>> problem that you're running into, please independently open your own
>> bug;
>> the more customers they know this affects, the more likely we'll get
a
>> hot
>> fix.
> 

-- 

  Douglas E. Engert  <[EMAIL PROTECTED]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


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

RE: computer account change password with Windows 2008 domain

[Tim Alsop]

Ross,

Thankyou. If a hotfix is available, our partner support people at MS
will be able to get us same hotfix to test.

Regards,
Tim

-Original Message-
From: Wilper, Ross A [mailto:[EMAIL PROTECTED] 
Sent: 01 April 2008 22:44
To: Russ Allbery; Tim Alsop
Cc: kerberos@mit.edu; Srinivas Cheruku
Subject: RE: computer account change password with Windows 2008 domain

Our case SRZ080225000456 is open for the Windows 2008 KDC being unable
to authenticate any account with a "/" in the principal name. On this
case, we have been issued a private hotfix that appears to resolve the
issue. The hotfix is now in review for public release.

Our case SRZ080306000400 is open for the Windows 2008 LDAP server not
being able to negotiate QOP for SASL binds over SSL with OpenLDAP. This
case is still in the troubleshooting phase.

-Ross

-Original Message-
From: Russ Allbery [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 01, 2008 2:36 PM
To: Tim Alsop
Cc: kerberos@mit.edu; Srinivas Cheruku; Wilper, Ross A
Subject: Re: computer account change password with Windows 2008 domain

Ross, could you give Tim our reference numbers for our Microsoft bug
reports that we filed as part of Guest?  They're running into one of the
same issues, and I figure the more the merrier on the complaining.

"Tim Alsop" <[EMAIL PROTECTED]> writes:

> Russ,
>
> That's great information, thanks.
>
> We are using Kerberos set password protocol to change/set the computer
> account password, but since the SPN used contains a / I suspect we are
> experiencing the same issues you described.
>
> If you have any reference numbers for your problems, then I would like
> to mention them to MS when I talk to them tomorrow. 
>
> Thanks,
> Tim
>
> -Original Message-
> From: Russ Allbery [mailto:[EMAIL PROTECTED] 
> Sent: 01 April 2008 22:17
> To: Tim Alsop
> Cc: kerberos@mit.edu
> Subject: Re: computer account change password with Windows 2008 domain
>
> "Tim Alsop" <[EMAIL PROTECTED]> writes:
>
>> We have discovered a problem when we try to set/change password for a
>> computer account in AD on Windows Server 2008. The computer account
is
>> created so we can use it for a service/application, and the key is
>> created from it's password (randomly generated) and extracted into a
> key
>> table file.
>>
>> Our code is able to create the account (authenticating to AD using
>> SASL/GSS/Kerberos) but when we try and set the computer account's
>> password to a random value, the request is rejected, so it looks like
> AD
>> on Windows 2008 has some changes which stop password changes for
>> computer accounts, or maybe something which is stopping changes to
>> passwords for accounts that use a principal name such as
>> name/[EMAIL PROTECTED]
>
> You don't say here *how* you're changing the password, but there are
two
> Active Directory bugs in Windows 2008 that you may be running into:
>
> * Authentication to Active Directory using a principal that contains a
>   slash (such as service/foo) from a keytab generated by the Windows
> tool
>   is broken in Windows 2008.  It works fine if there is no slash in
the
>   principal.  Microsoft has identified this as a bug and is working on
a
>   fix.
>
> * Microsoft broke password changes via the LDAP protocol with SASL
> GSSAPI
>   binds in Windows 2008.  In Windows 2003, provided that you didn't
try
> to
>   negotiate an SASL privacy layer, you could connect via TLS and
>   authenticate with GSSAPI and query or set the password attribute
>   directly.  In Windows 2008, this no longer works; you always get the
>   error from the server that you are not permitted to negotiate a
> privacy
>   layer when using TLS, even though you're not trying to.  We've
already
>   filed this as a bug.
>
> In both cases, if you have a support contract with Microsoft and this
is
> a
> problem that you're running into, please independently open your own
> bug;
> the more customers they know this affects, the more likely we'll get a
> hot
> fix.

-- 
Russ Allbery ([EMAIL PROTECTED])
<http://www.eyrie.org/~eagle/>


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

RE: computer account change password with Windows 2008 domain

[Tim Alsop]

Russ,

That's great information, thanks.

We are using Kerberos set password protocol to change/set the computer
account password, but since the SPN used contains a / I suspect we are
experiencing the same issues you described.

If you have any reference numbers for your problems, then I would like
to mention them to MS when I talk to them tomorrow. 

Thanks,
Tim

-Original Message-
From: Russ Allbery [mailto:[EMAIL PROTECTED] 
Sent: 01 April 2008 22:17
To: Tim Alsop
Cc: kerberos@mit.edu
Subject: Re: computer account change password with Windows 2008 domain

"Tim Alsop" <[EMAIL PROTECTED]> writes:

> We have discovered a problem when we try to set/change password for a
> computer account in AD on Windows Server 2008. The computer account is
> created so we can use it for a service/application, and the key is
> created from it's password (randomly generated) and extracted into a
key
> table file.
>
> Our code is able to create the account (authenticating to AD using
> SASL/GSS/Kerberos) but when we try and set the computer account's
> password to a random value, the request is rejected, so it looks like
AD
> on Windows 2008 has some changes which stop password changes for
> computer accounts, or maybe something which is stopping changes to
> passwords for accounts that use a principal name such as
> name/[EMAIL PROTECTED]

You don't say here *how* you're changing the password, but there are two
Active Directory bugs in Windows 2008 that you may be running into:

* Authentication to Active Directory using a principal that contains a
  slash (such as service/foo) from a keytab generated by the Windows
tool
  is broken in Windows 2008.  It works fine if there is no slash in the
  principal.  Microsoft has identified this as a bug and is working on a
  fix.

* Microsoft broke password changes via the LDAP protocol with SASL
GSSAPI
  binds in Windows 2008.  In Windows 2003, provided that you didn't try
to
  negotiate an SASL privacy layer, you could connect via TLS and
  authenticate with GSSAPI and query or set the password attribute
  directly.  In Windows 2008, this no longer works; you always get the
  error from the server that you are not permitted to negotiate a
privacy
  layer when using TLS, even though you're not trying to.  We've already
  filed this as a bug.

In both cases, if you have a support contract with Microsoft and this is
a
problem that you're running into, please independently open your own
bug;
the more customers they know this affects, the more likely we'll get a
hot
fix.

-- 
Russ Allbery ([EMAIL PROTECTED])
<http://www.eyrie.org/~eagle/>


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

computer account change password with Windows 2008 domain

[Tim Alsop]

Hi,

 

We have discovered a problem when we try to set/change password for a
computer account in AD on Windows Server 2008. The computer account is
created so we can use it for a service/application, and the key is
created from it's password (randomly generated) and extracted into a key
table file.

 

Our code is able to create the account (authenticating to AD using
SASL/GSS/Kerberos) but when we try and set the computer account's
password to a random value, the request is rejected, so it looks like AD
on Windows 2008 has some changes which stop password changes for
computer accounts, or maybe something which is stopping changes to
passwords for accounts that use a principal name such as
name/[EMAIL PROTECTED] 

 

The same code works perfectly on Windows Server 2003 domains, so we
suspect some changes in Windows Server 2008 have caused this set/change
password restriction.

 

Does anybody have any experience of same problem ?

 

Thanks,

Tim


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

RE: Kerberos delegation on Windows Vista LSA

[Tim Alsop]

Speedo,

This is due to a bug in Vista that will be fixed in SP1. There is a
hotfix available for pre-SP1. If you turn off UAC or use an account
which is not an administrator you don't need any fix.

The hotfix is described at http://support.microsoft.com/kb/942219/en-us

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Speedo
Sent: 28 January 2008 13:32
To: kerberos@mit.edu
Subject: Kerberos delegation on Windows Vista LSA

Hi Guys

I have a program doing Kerberos on Windows. The program generates all
Kerberos packets itself but will sometimes retrieve tickets from the
LSA cache so that user needn't type in the windows password. Before
WIndows Vista, if I have to go delegation, I need a forwardable TGT to
put into a KRB_CRED message. In order to get the session key, I have
to setup the Windows registry key allowtgtsessionkey=1. Now in Vista,
even if the key is set, a domain user who is in the local admin group
still cannot get a valid session key. The only workaround now is to
create my own kinit and issue the AS_REQ, which means the user has to
input his password, and the user is not happy.

I suppose Vista is doing this for security reason so that un-
privileged guys cannot use this "hole" to get back full admin right.
Is that right? Do this mean I can never 1) generating Kerberos packets
myself and 2) using LSA cache at the same time?

Thanks in advance
Speedo

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


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

RE: Kerberos SSO with SAP ERP (AIX) and SAP GUI

[Tim Alsop]

Rick,

Please check http://www.cybersafe.com/d2 and also
http://www.cybersafe.com/links/snc.htm

Please let me know if you would like to evaluate the solution described
on above websites. It is fully supported and SAP certified and available
for AIX 5L.

Regards,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Taylor, Richard
Sent: 17 January 2008 17:14
To: kerberos@mit.edu
Subject: Kerberos SSO with SAP ERP (AIX) and SAP GUI

Hi,

If possible, please point me to some successful documentation where
Kerberos V is used to setup Single Sign-On using Windows 2003 ADS and
AIX SAP servers.  We would like to be able to authenticate from our
desktop via ADS and then click on a SAP system from the SAP Login Pad
and achieve SSO into that application server running on AIX.

Any help is greatly appreciated!

Best Regards,
Rick Taylor 
OGE Energy Corp. 
SAP / Database Administrator 
phone: (405) 553-2426 
Mobile:  (405) 623-7537 



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: SSO implementation for SAP running on Solaris 10

[Tim Alsop]

Senthil,

Can I ask why you don't want to use any 3rd party tools to implement SSO
with your SAP systems ?

Anyway, you might want to check http://www.cybersafe.com/d2 then click
on the link provided, and watch the flash videos to see how to setup SSO
with SAP GUI.

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Senthil Murugan Muthuvelu
Sent: 26 December 2007 10:25
To: kerberos@mit.edu
Subject: SSO implementation for SAP running on Solaris 10


Hi

I'm in the process of implementing SSO for SAP systems. The systems
in the landscape include DEV-QA-PRD and some sandbox also.

We want to achieve Desktop SSO so that users are not asked to re-enter
access credentials (password, username). Once an user signs in one of
the systems in the landscape, he can access other systems listed in SAP
logon pad (within the landscape) with other systems.

We are also not interested to use any 3rd party tools

Can someone give pointers and detailed process steps as how this can
be achieved by using SP-NEGO and Kerberos in SAP systems running under
Solaris 10 with Windows clients. Note that all the clients are in MS-
Windows

At the moment, we have MS-LDAP where users are being maintained for
Portal.

Warm regards
Senthil


 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
solely for the use of the addressee(s). If you are not the intended
recipient, please notify the sender by e-mail and delete the original
message. Further, you are not to copy, disclose, or distribute this
e-mail or its contents to any other person and any such actions are
unlawful. This e-mail may contain viruses. Infosys has taken every
reasonable precaution to minimize this risk, but is not liable for any
damage you may sustain as a result of any virus in this e-mail. You
should carry out your own virus checks before opening the e-mail or
attachment. Infosys reserves the right to monitor and review the content
of all messages sent to or from this e-mail address. Messages sent to or
from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***


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: Account lockout support in Solaris 10 when authenticatingagainstKerberos

[Tim Alsop]

See my feedback below, prefixed with Tim>

On Tue, Dec 11, 2007 at 10:57:51AM -0800, Russ Allbery wrote:
> 
> This is one of those "features" that keeps showing up in commercial
> products because it made it into some management checklist, 

Not just any mindless management checklist, but various government
checklists, such as NISPOM ch. 5 (which is a requirement for systems
that contain U.S. government classified information).

So in addition to the traditional reasons why this feature has never
shown up in MIT Kerberos:

* Can actually do more harm than good by creating a trivially
  easy attack vector

Tim> Agreed, but we need to recognise that many security departments
want/need this functionality, and if they don't it can always be
disabled ...

* Hard to do 100% right in the presence of slave KDC's (which would
  now have to keep state and all KDC's would need a mechanism to
  propagate said state to all of the other KDC's).

Tim> yes, it is hard, but the CyberSafe TrustBroker Security Server
product has this already implemented, and it works very well. As
somebody mentioned in an earlier post, this functionality is also
implemented in Microsoft Active Directory and works very well when AD is
used as KDC.

There's one additional twist:

* Many of the sites that need this feature are so paranoid that having a
  vendor supply a binary which can NOT be independently audited is
  easier to get past the security folks than some open source package
  since if source is available, the security people want the whole
  darned package to be reviewed before allowing it on the classified
  network.

Tim> This is one reason why we build and support a commercially
available Kerberos product, including client and KDC software. There are
many companies and organisations that prefer to buy our commercially
supported product instead of using open source. Also, the software
license cost is not as high as you might think :-)

Note that I'm not saying this makes sense; I'm just describing the way
the world works for some interesting subset of Kerberos-using sites.

- Ted

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: Account lockout support in Solaris 10 when authenticatingagainstKerberos

[Tim Alsop]

This is not strictly true - the statement below should say "If using the
MIT KDC, there is no way to do this at the Kerberos level". The reason
is that our commercially supported KDC (TrustBroker Security Server)
supports this functionality you are asking about. Our secondary KDC
passes failed auth attempt count to the primary KDC so that this count
can then be incrementaly propagated to other secondaries. This means,
when using our product an account is disabled after a preconfigured
number of failed auth attempts regardless of which KDC (or KDCs) they
use to authenticate.

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Yu, Ming
Sent: 11 December 2007 02:03
To: [EMAIL PROTECTED]; kerberos@mit.edu
Subject: Re: Account lockout support in Solaris 10 when
authenticatingagainstKerberos

Russ, 

   Thanks for the help.

   That is th info I am looking for.

   Ming

- Original Message -
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: kerberos@mit.edu 
Sent: Mon Dec 10 20:45:49 2007
Subject: Re: Account lockout support in Solaris 10 when authenticating
againstKerberos

"Yu, Ming" <[EMAIL PROTECTED]> writes:

>   But I am still not clear how to "lock out" account after n-times of
>   failed login.
>  
>   Are you saying there is no way to do it in current version of MIT
>   kerberos?

Right, there's no way to do it at a Kerberos level.  There are various
things that you can do within the service that's authenticating, but it
may require development on your part.  (For example, if you're
authenticating the user via PAM, you could store the PAM failure count
somewhere and reject logins to that user once the failures reach a
particular threshold, something you could do without modifying anything
about how Kerberos works.)

Converting a failed authentication compromise into a denial of service
attack is generally a stupid idea, IMO.  Far better to start rejecting
packets from a host that's apparently trying to do a dictionary attack.

-- 
Russ Allbery ([EMAIL PROTECTED])


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


DISCLAIMER:
Important Notice *
This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intended
recipient of this e-mail, do not duplicate or redistribute it by any
means. Please delete it and any attachments and notify the sender that
you have received it in error. Unintended recipients are prohibited from
taking action on the basis of information in this e-mail.E-mail messages
may contain computer viruses or other defects, may not be accurately
replicated on other systems, or may be intercepted, deleted or
interfered with without the knowledge of the sender or the intended
recipient. If you are not comfortable with the risks associated with
e-mail messages, you may decide not to use e-mail to communicate with
IPC. IPC reserves the right, to the extent and under circumstances
permitted by applicable law, to retain, monitor and intercept e-mail
messages to and from its systems.

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: Implementing OTP mechanism with existing kerberos

[Tim Alsop]

Gopal,
 
Sorry if I mislead you in any way. I don't think I mentioned MIT
Kerberos in my email. The product I used is called TrustBroker and is
commercially available from CyberSafe, and is not based on MIT or
Heimdal, and is not open source. I just wanted to show you so you can
see that what you are trying to do can be done ... I also thought you
might be interested in a commercially supported solution to meet your
two-factor authentication needs. If you plan to continue developing your
own solution with MIT then I wish you the best of luck, but if you are
interested in our products please let me know.
 
Take care,
Tim



From: Gopal Paliwal [mailto:[EMAIL PROTECTED] 
Sent: 25 July 2007 22:44
To: Tim Alsop; kerberos@mit.edu
Subject: Re: Implementing OTP mechanism with existing kerberos


hi Tim,
 It's really nice.
i could see that you are able to use hardware tokens with MIT kerberos.
If u are comfortable, could you explain me the way you have done it. 
it will be great.
 
-gopal

 
On 7/25/07, Tim Alsop <[EMAIL PROTECTED]> wrote: 

Gopal,

It is not easy to do. If you are interested, we already have a
solution
- see example below : 

# kinit talsop
Password for [EMAIL PROTECTED]:
Enter Passcode (PIN+Tokencode) or Tokencode from your SecurID
Token:
# klist -ef
 Cache Type: Kerberos V5 Credentials Cache
 Cache File: /krb5/tmp/cc/krb5cc_0 
  Cache Version: 0502
  Default Principal: [EMAIL PROTECTED]

Valid FromExpires
Service
Principal
  
- 
Wed 25 Jul 2007 22:24:51 BST  Thu 26 Jul 2007 06:24:41 BST
krbtgt/[EMAIL PROTECTED]
  Session Key EType:  5 (DES3-CBC-MD5)
   Ticket EType:  5 (DES3-CBC-MD5)
   Ticket Flags: IHA
#

Note the H flag in ticket flags - this indicates that hardware
token was 
used to obtain the TGT.

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On
Behalf Of Gopal Paliwal
Sent: 25 July 2007 21:31
To: kerberos@mit.edu
Subject: Implementing OTP mechanism with existing kerberos

Hi,

I am implementing OTP mechanism in the existing kerberos. 
I have set up pre-auth mechanism to authenticate the clients.
Now, the user will be asked password+OTP instead of just
password. i
will be
generating this OTP with a hardware token.

Also, i will be encrypting time-stamp with password & OTP. 
At the kerberos authentication server, I will be able to
generate a OTP.

Now, the problem which I will face is that kerberos doesn't
store
passwords
in clear form. & I somehow need to form a key at kerberos
authentication 
server side to decrypt the time-stamp sent in the AS_REQ message
by
user.
That key will be made up of OTP + password.
Can someone point me out the mechanism as to how can I obtain
password
in
clear form or other way with which I will be able to resolve my
doubt. 

-gopal

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: Implementing OTP mechanism with existing kerberos

[Tim Alsop]

Gopal,

It is not easy to do. If you are interested, we already have a solution
- see example below :

# kinit talsop
Password for [EMAIL PROTECTED]:
Enter Passcode (PIN+Tokencode) or Tokencode from your SecurID Token:
# klist -ef
  Cache Type: Kerberos V5 Credentials Cache
  Cache File: /krb5/tmp/cc/krb5cc_0
   Cache Version: 0502
   Default Principal: [EMAIL PROTECTED]

Valid FromExpires   Service
Principal
  
-
Wed 25 Jul 2007 22:24:51 BST  Thu 26 Jul 2007 06:24:41 BST
krbtgt/[EMAIL PROTECTED]
   Session Key EType:  5 (DES3-CBC-MD5)
Ticket EType:  5 (DES3-CBC-MD5)
Ticket Flags: IHA
#

Note the H flag in ticket flags - this indicates that hardware token was
used to obtain the TGT.

Thanks,
Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Gopal Paliwal
Sent: 25 July 2007 21:31
To: kerberos@mit.edu
Subject: Implementing OTP mechanism with existing kerberos

Hi,

I am implementing OTP mechanism in the existing kerberos.
I have set up pre-auth mechanism to authenticate the clients.
Now, the user will be asked password+OTP instead of just password. i
will be
generating this OTP with a hardware token.

Also, i will be encrypting time-stamp with password & OTP.
At the kerberos authentication server, I will be able to generate a OTP.

Now, the problem which I will face is that kerberos doesn't store
passwords
in clear form. & I somehow need to form a key at kerberos authentication
server side to decrypt the time-stamp sent in the AS_REQ message by
user.
That key will be made up of OTP + password.
Can someone point me out the mechanism as to how can I obtain password
in
clear form or other way with which I will be able to resolve my doubt.

-gopal

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: Implementing OTP mechanism with existing kerberos

[Tim Alsop]

Gopal,

It is not easy, but once it is done you get a nice solution - see below
:
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Gopal Paliwal
Sent: 25 July 2007 21:31
To: kerberos@mit.edu
Subject: Implementing OTP mechanism with existing kerberos

Hi,

I am implementing OTP mechanism in the existing kerberos.
I have set up pre-auth mechanism to authenticate the clients.
Now, the user will be asked password+OTP instead of just password. i
will be
generating this OTP with a hardware token.

Also, i will be encrypting time-stamp with password & OTP.
At the kerberos authentication server, I will be able to generate a OTP.

Now, the problem which I will face is that kerberos doesn't store
passwords
in clear form. & I somehow need to form a key at kerberos authentication
server side to decrypt the time-stamp sent in the AS_REQ message by
user.
That key will be made up of OTP + password.
Can someone point me out the mechanism as to how can I obtain password
in
clear form or other way with which I will be able to resolve my doubt.

-gopal

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


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

RE: kerberos + securid (hpcmp)

[Tim Alsop]

David,

I can tell you that the CyberSafe commercially available Kerberos
products support using SecurID to get the initial TGT. This is not an
open source solution so you would have to pay for our products to use
this functionality.

I also need to advise you that to support the pre-authentication for
SecurID the KDC, and also the clients need SecurID support - e.g. it is
not something you can just add to the KDC only.

If you are interested to find out more about our products please let me
know.

Take care,
Tim Alsop
CyberSafe Limited 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David Bishop
Sent: 25 May 2007 18:11
To: kerberos@mit.edu
Subject: kerberos + securid (hpcmp)

Good morning!

I work at a largish retail company, who is being affected by the
PCI-DSS.  One of the changes we are making is implementing one-time
passwords to access any of our production machines (use RSA SecurIDs).
We have that working using the standard PAM module, but are already
annoyed at having to enter a PIN everytime we get on any machine
(something that we do tens of times per day).

Our first thought was to have a couple of "gateway" machines, that you
have to use a securid to log into, then allow sshkeys[1] from there to
the
other machines - while still allowing "direct" access to the machines
using RSA.  However, there is no way to change the order of
authentication in sshd, server-side (to do the PAM-checks of IP,
then determine whether to use RSA or sshkeys), and client-side isn't
good enough (for obvious reasons).

That is a long-winded way of saying that we are seriously considering
using kerberos.  However, we would still need to use RSA SecurID for the
initial authentication, to get the TGT.  The only thing I can find after
googling for a while is that I (apparently) need to use the HPCMP flavor
of kerberos to have that functionality, but *nowhere* can I find a link
to the source code, in order to build our own kdc, or the various
Solaris and Linux clients (as we aren't using Solaris8 or debian/SuSE -
the only binary clients I could readily find).

My question is: am I the worst googler ever?  Is, perchance, securid
support built into the latest krb5 release, and I just can't find
documentation on it?  Am I just SOL?  Is there a different way to
accomplish what we desire (that isn't kludgy, like running multiple sshd
instances)?

Many, many thanks for those of you who read this far.  Have a great day!

David

[1] using ssh-agent, of course

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: Problem with case insensitive user names in AD

[Tim Alsop]

Douglas, Srinivas,

During my testing I have observed strange, inconsistent results, but
similar to the findings of yourself and Srinivas. See below :

I have found that you need to use the default enc type for user accounts
(e.g. RC4-HMAC), e.g. you do not have the "Use DES" flag set in the
account properties. If the "Use DES" flag is set, then some issues,
which MS have decided not to fix (to encourage use of non-DES ciphers)
become aparent related to case sensitivity of principal names.

In my test environment I have a Windows Server 2003 SP1 system running a
domain with Active Directory. All latest fixes are applied, by using
Windows Update.

In Windows logon screen, I enter account name [EMAIL PROTECTED] After logon,
principal name of TGT in cache (displayed using kerbtray) = [EMAIL PROTECTED]
- This is correct because the principal name in the cache is based on
the case of account, as it is defined in AD.

In Windows logon screen, I enter account name USer, and select domain
XXX.COM. After logon, principal name of TGT in cache (displayed using
kerbtray) = [EMAIL PROTECTED]
- This is NOT correct because the principal name in the cache is based
on the case of the account name entered in logon screen, which might not
be the same each time the user logs on.

So, from the above, it looks like there is a bug in MS AD on Windows
Server 2003 SP1, that occurs only when a UPN is not used during user
logon to Windows.

However, on a different server running Windows Server 2003 SP1, with all
latest fixes applied, when I logon using UPN and non-UPN logon I get a
principal name in the Microsoft cache based on the case of the user as
defined in AD, and not in any way related to the case of user name
entered during initial logon. Clearly this is not the same as on my
other server, as I described above, but it is hard to know what the
differences are since they were both built the same way. 

Also, if I found if I run the same tests described above using a Windows
2000 DC that I have in my test environment, then both UPN and non-UPN
account name logon methods work as I would expect. e.g. the principal
name in cache after the logon is based on the case of account name in
AD, not using the case of the user account name entered at initial
Windows logon.

I would be interested to hear if anybody else has experienced the same
inconsistencies ?

This is all possible because MS Windows is specifying the canonicalize
flag in the Kerberos AS-REQ. This is recognised by AD and it allows a
principal name with a case other than the one requested to be used when
issuing the TGT. Some implementations of Kerberos do not set the
canonicalize flag in AS-REQ, and therefore the above may not be observed
if a non-Microsoft Kerberos library (e.g. MIT code or Java) is used to
request the TGT. With these implementations the case of the principal in
cache will be same as case of principal in AS-REQ.

You mentioned in your reply that you "use lower case account names for
users". This is fine, but what happens if a user enters any upper case
characters for their account during Windows logon ? Do you still see the
principal in Microsoft cred cache as @ or is it
@ ? It would be useful if you can
confirm this to see if you are getting same results as we are.

Thanks,
Tim


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Douglas E. Engert
Sent: 12 January 2007 16:42
To: Srinivas Cheruku
Cc: kerberos@mit.edu
Subject: Re: Problem with case insensitive user names in AD



Srinivas Cheruku wrote:
> Hi,
> 
> We have an environment consisting of Win2k and Win2k3 servers and 
> workstations with Window XP SP2.
> The users created in AD are with lower case user principal names. eg: 
> [EMAIL PROTECTED]

We ran into a problem like this too. Account names in AD are case
insensitive.
Kerberos principals are case sensitive. So windows will accept any case
and will return a ticket with some case. I think W2K3 is trying to
do the best it can in this case :-).

(Java had a problem with pre-auth and the salt with DES, as it assumed
it
know the principal with case and thus the salt. The salt is case
sensitive.
Java 1.6 fixed this.)

Our solution, use lower case account names for users.

This means you can not have two principal names in AD that differ
only by case.

> 
> While logging to Win2k3 AD using winlogon from WinXP, I have used the 
> user name in mixed case eg: Scheruku in the WinLogon screen for 
> authenticating.
> I have observed the following,
> 1. In the Windows Credential cache, the TGT is with the client
principal 
> name as [EMAIL PROTECTED] though the correct client name (UPN) is 
> [EMAIL PROTECTED]
> 2. I checked using ethereal and the AS-REQ, contains :
>  2.1 Canonicalization flag set.
>  2.2 client name: Scheruku (as given in logon screen)
> 3. AS-REP
>  3.1 client name: Scheruku (as given in logon screen)
> 
> I think the TGT should be with the client name as that of
sAMAccountName 
> which is not t

RE: Validation with Kerberos 5, SAP, Solaris, SNC for SSO

[Tim Alsop]

Eugene,

If you would like a supported, working, and SAP Certified product which
uses Kerberos, and is fully supported for use with all available
versions of Active Directory, and SAP products then please check
http://www.cybersafe.com/links/snc.htm.

Please let me know if you have any questions, or would like to undertake
a free evaluation of the above mentioned product.

Happy Christmas.

Take care,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Eugeny Kraynukov
Sent: 22 December 2006 15:55
To: kerberos@mit.edu
Subject: Validation with Kerberos 5, SAP, Solaris, SNC for SSO

* We want to install Single Sign on functionality for SAP, with
BC-SNC, Kerberos 5 and Active
** Directory, but when we configure SNC in SAP with kerberos we have a
validation error as soon as
** start SAP.
** Notice:
** We have installed SAP over Solaris which has Kerberos 5, the
library that we are using is
** libgssapi_krb5.so.
** The domain controllers of the AD are Windows 2003.
**
** The configuration seems to be ok, we create the accounts in the AD
(Solaris server account
** "hostname"), however when SAP starts we FIND the
** following
** error:
**
*SncInit(): Initializing Secure Network Communication (SNC)
NSolaris on x86_64 CPU (st,ascii,SAP_UC/size_t/void* = 16/64/64)
N  SncInit():   found snc/data_protection/max=1, using 1 (Authentication
Level)
N  SncInit():   found snc/data_protection/min=1, using 1 (Authentication
Level)
N  SncInit():   found snc/data_protection/use=1, using 1 (Authentication
Level)
N  SncInit(): found  snc/gssapi_lib=/usr/lib/gss/snckrb5.so
NFile "/usr/lib/gss/snckrb5.so" dynamically loaded as SNC-Adapter.
NThe Adapter identifies as:
NExternal SNC-Adapter (Rev 1.0) to Kerberos 5/GSS-API v2
N  *** ERROR => SncPGSSImportName()==SNCERR_GSSAPI  [sncxxall.c 2637]
NGSS-API(maj): A supplied name was of an unsupported type
N  Import of a name failed
N  name="p:host/[EMAIL PROTECTED]"
N  <<- SncInit()==SNCERR_GSSAPI
N   sec_avail = "false"
M  ***LOG R19=> ThSncInit, SncInitU ( SNC-04) [thxxsnc.c230]
M  *** ERROR => ThSncInit: SncInitU (SNCERR_GSSAPI) [thxxsnc.c232]
M  in_ThErrHandle: 1
M  *** ERROR => SncInitU (step 1, th_errno 44, action 3, level 1)
[thxxhead.c   10126]*
**
** I can't find any information for the error code.
** Could you please help me with this problem?
**
** Thanks in advance!*

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: Using kerberos ticket on web browsers

[Tim Alsop]

Diego,

There must be something wrong in my setup (obviously), but I'm sure it
isn't
on the server side, since Linux clients are able to authenticate
properly.
I've come to the conclusion that firefox is using NTLM by sniffing
network
packets (I can send them if anyone is interested, but I don't think its
relevant).

Regarding the above - the browser will try and authenticate to server
using NTLM if it is unable to get the kerberos ticket, so I suggest you
check that the client is able to get the ticket from KDC. As I mentioned
in my last message, if you are accessing a web page with URL
http://server.domain.com then firefox will try to request a service
ticket with principal name HTTP/server.domain.com@. Is there any
traffic between client and KDC when you try to authenticate ? Perhaps
KDC is returning an error ?

Thanks,
Tim


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

RE: Using kerberos ticket on web browsers

[Tim Alsop]

Diego,

What URL are you using when you request access to the web site ? E.g. if you 
enter http://server.domain.com, the browser will request a service ticket 
called HTTP/server.domain.com@. Perhaps you can check if the 
cache on workstation contains this ticket after you attempt to logon ?

Thanks,
Tim

-Original Message-
From: Diego Lima [mailto:[EMAIL PROTECTED] 
Sent: 06 December 2006 14:15
To: Tim Alsop; Julio Cesar Parra/Mexico/IBM; Kerberos Mail List
Subject: RE: Using kerberos ticket on web browsers

On Tue, 5 Dec 2006 19:41:23 -, Tim Alsop wrote

> It is not possible to configure IE to use anything other than LSA 
> for getting credentials, however Firefox can be configure to use a 
> GSS-API library

Thank you for your tip, I was able to find some documents regarding
configuring firefox by searching "firefox gss-api" on google. I've set the
following options on about:config :

network.negotiate-auth.gsslib C:\Arquivos de
programas\MIT\Kerberos\lib\i386\gssapi32.lib
network.negotiate-auth.trusted-uris   http://, https://
network.negotiate-auth.using-native-gsslibfalse

I've got a valid ticket on krb5cc but I'm still getting permission denied on
the protected webpage, although I can access it from a linux machine using the
same principal.

I've sniffed the packets and I see that firefox is answering the negotiate
request with a "NTLMSSP_NEGOTIATE" request, whereas on linux I don't see the
NTLMSSP part.

Here is the answer firefox gives: 

[EMAIL PROTECTED])[EMAIL PROTECTED] /apache2-default/protegido HTTP/1.1
Host: 192.168.130.222
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1)
Gecko/20061010 Firefox/2.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0, max-age=0
Authorization: Negotiate 
TlRMTVNTUAABB4IIogAFASgKDw==
NTLMSSP(

I have already tried to restart firefox but I'm still getting this error. I
have tried to acquire other tickets, but I get the same error, even with the
same negotiate identification (if that's indeed some kind of id).

Am I missing something? Do I have to configure MIT's gss api with anything
other than krb5.ini on my windows directory?
--

Diego Alencar Alves de Lima
DINF - Prodesan (http://www.prodesan.com.br)
Prefeitura Municipal de Santos (http://www.santos.sp.gov.br)


-- 

Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.



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

RE: Using kerberos ticket on web browsers

[Tim Alsop]

Diego,

It is not possible to configure IE to use anything other than LSA for getting 
credentials, however Firefox can be configure to use a GSS-API library, so you 
can configure Firefox to use the MIT gss dll and then it can access credentials 
obtained by your GINA.

To find out how to configure Firefox, look in help or let me know if you get 
stuck.

Thanks,
Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Diego Lima
Sent: 05 December 2006 19:32
To: Julio Cesar Parra/Mexico/IBM; Kerberos Mail List
Subject: Re: Using kerberos ticket on web browsers

Hello again,

We don't have any windows AD server on the network (actually, we have no 
Windows servers, AD or not). Currently we get our tickets from a Debian 
server configured with a Samba+OpenLDAP+MIT Kerberos. While windows doesn't 
get a ticket at logon, we use a combination of MIT for Windows and a custom 
GINA to acquire the tickets from our Kerberos KDC.

These tickets are stored in two places: a file on a network share and the 
MIT API krb5cc; We have no tickets in the LSA, which (I believe) is where IE 
and Firefox are trying to get the tickets from, and we need to point them 
towards either ticket location (file or API).

Thank you,

--

Diego Alencar Alves de Lima
DINF - Prodesan (http://www.prodesan.com.br)
Prefeitura Municipal de Santos (http://www.santos.sp.gov.br)


On Tue, 5 Dec 2006 11:33:56 -0600, Julio Cesar Parra/Mexico/IBM wrote
> Hi maybe these steps can help you with you problem.
> 
> If you are logging into an win AD server that is not on the same 
> domain as the webserver, you must do the following on the client 
> PC's Broswer to trust that site (so it sends kerb ticket)
> 
> 1.In Internet Explorer, click Tools, and then click Internet Options.
> 
> 2.Click the Security tab, then click Local intranet, then click 
> Sites, and then click Advanced.
> 
> 3.In the Add this Web site to the zone: text box, type the name of 
> the website you want to authenticate to with Kerberos authentication,
>  and then click Add.
> 
> 4.Click OK.
> 
> Regards.
> 
> *  Carpe diem
> Julio Cesar Parra Uribe   E-mail: [EMAIL PROTECTED] 
> T/L   877-2535 Ext phone:  (5233)3669-7000  Ext.  2535 
> Project Manager
> SY-KRB-CP-EZ-HFS-BATS-RC-MN-REXX
> TRCTCPAPP-ISQL-QRY400 Guad Team.

-- 
Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.


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


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

RE: Kerberos support in Sybase Powerbuilder 9 and 10 and Open Client12.5.1

[Tim Alsop]

Markus,

The Open Client uses GSS-API, and when used with the CyberSafe
TrustBroker Application Security Runtime Library or the Secure Client
for Windows products are able to access credentials in MS cache, via LSA
API. The effect is exactly same as if OC was using SSPI on Windows,
since it can access credentials obtained when the user logged onto the
workstation via an AD domain account.

Regards,
Tim Alsop
CyberSafe Limited 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Markus Moeller
Sent: 03 December 2006 13:18
To: kerberos@mit.edu
Subject: Kerberos support in Sybase Powerbuilder 9 and 10 and Open
Client12.5.1

Does anybody know if Powerbuilder/OpenClient supports AD via
SSPI/Kerberos ? 
I could only find SSPI/NTLM and Cybersafe/MIT Kerberos support.

Thanks
Markus





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

RC4 weakness ?

[Tim Alsop]

Hi,
 
I have heard recently that with RC4 there appears to be a generic
weakness with the standard implementation of the algorithm.  Research by
Fluhrer, Mantin and Shamir demonstrated that all RC4 keys are vulnerable
to brute-forcing attacks as the first few bytes of output keystream are
non-random.  Thus information about the key can be deduced by an
attacker so reducing the computational effort required to de-crypt the
message.
 
The recommended crypto-system defence against this attack is to discard
the initial portion of the keystream (e.g.  the first 1024 bytes) before
using it.  This removes the predictable part of the key making it harder
to brute force the encryption key.
 
Can somebody let me know how the Kerberos standard use of RC4 addresses
this issue ?
 
Thanks
Tim
 

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

RE: Kerberized DBMS's Available

[Tim Alsop]

Sybase also supports Kerberos, but does not embed Kerberos libraries
like Oracle decided to, instead it uses a GSS-API interface.

I also understand that IBMs database product supports Kerberos, but I
have limited experience of it to comment. I beleive they have
implemented the interface to the Kerberos libraries using exits, so if
you don't like how it works you can code new security exits to implement
your own Kerberos authentication needs.

Thanks,
Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Henry B. Hotz
Sent: 05 October 2006 18:57
To: kerberos@mit.edu
Subject: Kerberized DBMS's Available

I'm looking for a DBMS that supports Kerberos for user authentication  
and has a JDBC client.  It appears that I may have to write the  
support myself, unless someone can add something I haven't been able  
to find out.

The "big three" I know about are:

MySQL -- market leader, but no Kerberos support.  Also AFAIK no  
ability to use the identity from an SSH or SSL tunnel.  SASL/GSSAPI  
patches probably acceptable if offered.

PostgreSQL -- supports Kerberos directly with the MIT API.  No SASL/ 
GSSAPI support so Kerberos support doesn't work with the JDBC client,  
or on Windows (unless you build against KfW presumably).  GSSAPI  
patches probably acceptable if done "cleanly".

Oracle -- supports Kerberos directly using some pre-release MIT code  
independent of available any outside Kerberos libraries.  Not sure if  
our site license allows export of the client, or if they have a  
Kerberos aware JDBC client.  I expect not for at least one of those.




The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]



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: Error in client with kerberos and SAP SSO

[Tim Alsop]

Hi,

I recommend that you report this to SAP, since you are using the SAP
supplied SSPI wrapper library (gsskrb5.dll), which is displaying this
error. The error means that the SAP gss library was unable to find any
Kerberos ticket in the Microsoft credentials cache for the given user
principal name.

Thanks,
Tim Alsop
CyberSafe Limited

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Raunitschke, Sascha
Sent: 29 September 2006 14:33
To: kerberos@mit.edu
Subject: Error in client with kerberos and SAP SSO

Hi@ Juan Manuel Sestelo,

 

I'm very interested if you have solved the problem "Error in client with
kerberos and SAP SSO".

I have exactly the same problem as you have reported in this forum and I
wonder if you can provide me the solution.

 

Problem description:

Hi, 
I have implemented an SSO solution with kerberos5, SNC, Active Directory
2K3 with SAP(Unix
Server). It Works fine, but I found an error in some clients that I want
to investigate.
 
Some days, in the morning (note: users don't close the windows sessions
at the end of work-day,
they block-out their computers), when users try to connect to SAP, they
receive the following
client error (in the SAP client log):
 
**
Sapgui 620 [Build 8966] Wed Feb 16 10:03:14 2005: 'GSS-API(maj): No
valid credentials provided (or
available) GSS-API(min): No Kerberos SSPI credentials available for
requested nam
name="p:user at SITE.DOMAIN.COM
<https://mailman.mit.edu/mailman/listinfo/kerberos> "
Component  SNC (Secure Network Communication)
Release620
Version5
Module sncxxall.c
Line   1223
Method SncPAcquireCred
Return Code-4
System Callgss_acquire_cred
Counter4
**
 
or this one:
 
**
Sapgui 620 [Build 8966] Tue Feb 15 10:21:59 2005 : 'SNCERR_GSSAPI
An operation failed at the GSS-API level sec_avail="false"
Component  SNC (Secure Network Communication)
Release620
Version5
Module sncxx.c
Method SncInit
Return Code-4
Counter2
**
 
The problem ends if the user close it windows session and start it
again.
Someone knows this error? 

 

 

 

 

Thanks for you help/answer in advanced.

 

Regards,

Sascha

 

 

 

 

 

 


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: SSO and SAP

[Tim Alsop]

Laura,

In addition to Eric's note - You also need to be aware that there are a
few commercial products available which use Kerberos for SAP Security,
and SSO, that are fully supported, and some are SAP Certified to work
with the SNC interfaces, so if your company is planning to use SNC with
Kereberos, and are concerned about being supported you should consider
looking at one of the SAP Certified products available which use the SNC
interface. The SAP website lists them. I can send you the URL if you are
interested.

Thanks,
Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Labiner
Sent: 20 September 2006 12:34
To: kerberos@mit.edu
Subject: Re: SSO and SAP

Hi Laura,

There's a document about SSO config for SAP on Linux:
http://mailman.mit.edu/pipermail/kerberos/2004-November/006640.html

The general steps are:
1. Install MIT Kerberos on the Unix machine.
2. Compile the SAP SNC adapter.
https://www.sdn.sap.com/irj/sdn/thread?messageID=2298312
ftp://ftp.sap.com/pub/ietf-work/gssapi/
3. Follow the general SNC configuration scenario SAP:
http://help.sap.com/saphelp_nw2004s/helpdata/en/44/0ebb40b9920d1be10
00a114a6b/frameset.htm

Have a read here too:
https://www.sdn.sap.com/irj/sdn/thread?messageID=2298312

A small note: SAP does not support any problems with the MIT krb and
the snc adapter is a discontinued product.

I'm doing the same pilot for AIX 5.3.

Regards,
Eric Labiner
SAP NetWeaver consultant


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: leash session key type NULL

[Tim Alsop]

You need to set the AllowTGTSessionKey registry setting if you want to
see the Session Key etype, otherwise it will be shown as 0.

Thanks,
Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Markus Moeller
Sent: 18 September 2006 14:37
To: kerberos@MIT.EDU
Subject: leash session key type NULL

I am using leash 2.5  and when I import tickets from the MS cache  I get
for 
some users a session key type of NULL whereas the ticket encryption type
is 
RC4-HMAC-NT.  When I use get tickets with username/password I get the 
corrrect session key type of RC4-HMAC-NT.  Does anybody know why ?  I am

running on Win XP with a w2k3 kdc.

Thanks
Markus 



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: Credential cache file format documentation

[Tim Alsop]

Jeffery,

Without looking at our code, I cannot be sure of all of the cases where
we use the KDC IP address (stored in cache). However, one case where I
know it is used, is when we report it to the user, when they use "klist
-a". This allows the user to know which KDC (or KDCs) have a clock which
is out of sync with the client clock. For cache type 1,2 and 3 we store
the IP address of KDC in the ticket address field (e.g. the same place
where IP addresses are stored in tickets if requested during
AS-REQ/AS-REP exchange. We cannot assume that the clock on all KDCs for
a particular domain are in sync. Just like we cannot assume that the
client clock is in sync with the KDC.

Thanks,
Tim 

-Original Message-
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] 
Sent: 13 September 2006 18:12
To: Tim Alsop; Simon Josefsson
Cc: kerberos@mit.edu; Jeffrey Hutzelman
Subject: RE: Credential cache file format documentation



On Wednesday, September 13, 2006 05:31:13 PM +0100 Tim Alsop 
<[EMAIL PROTECTED]> wrote:

> For cache type 1,2 and 3 we currently store deltatime info in a hidden
> ticket in the cache, and we also store the IP address of the KDC where
> the time offset came from. The deltatime header tag does not currently
> allow any way to store this ip address, so this is what we were
thinking
> of adding, into a new tag.

What do you use that information for?


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

RE: Credential cache file format documentation

[Tim Alsop]

Simon,

Thanks. This makes sense and is consistent with what we concluded when
looking into this by checking MIT code.

For cache type 1,2 and 3 we currently store deltatime info in a hidden
ticket in the cache, and we also store the IP address of the KDC where
the time offset came from. The deltatime header tag does not currently
allow any way to store this ip address, so this is what we were thinking
of adding, into a new tag. From what you said, and from what we have
observed, the MIT code will ignore any tags it does not recognise. We do
also, in case somebody else uses these tags for propriatory reasons.

Thanks again,
Tim

-Original Message-
From: Simon Josefsson [mailto:[EMAIL PROTECTED] 
Sent: 13 September 2006 17:20
To: Tim Alsop
Cc: kerberos@mit.edu
Subject: Re: Credential cache file format documentation

Tim,

As far as I know, the header tags are not described anywhere.

I have looked at both the MIT and Heimdal source code, and they appear
to skip any unknown tags properly.  So it would appear possible to add
a new tag without causing problems in existing MIT/Heimdal clients.  I
have not tested this though.

The ccache format is less flexible than the Shishi ticket file format,
so to be able to fully switch to the ccache format in Shishi, I may
add a header tag to store additional information that Shishi can
understand.  I'm still quite skeptical about this though; we'll likely
only read/write the ccache format for compatibility and not use it as
the real ticket file, and in that case, there is no need to duplicate
the information in the ccache file.  But this is still an open
question..  it may be an issue that the key is stored in two different
files.

If you experiment with new tags, I'd be interested to hear about it if
you run into any problem.

I have updated the description with more details about header tags,
and some notes about the DeltaTime tag, see:

http://josefsson.org/shishi/ccache.txt

Thanks for your comments!

/Simon

"Tim Alsop" <[EMAIL PROTECTED]> writes:

> Simon,
>
> If you can, it would be useful if you can document the cache type
0x0504
> differences, e.g. what the header tag/tags contain, and in what
format.
> We recently made some changes to our products, and in order to test
the
> cache interoperability I tried to find documentation on the header
tags,
> but couldn't. We are also considering adding a new header tag but
cannot
> do this without understanding if there are any interop issues that
this
> may cause. I could not find any doc which indicates whether it is
> possible to add additional information into a cache header, if cache
> type is 0x0504. Do you know whether this is described anywhere ?
>
> Thanks,
> Tim
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Simon Josefsson
> Sent: 13 September 2006 16:44
> To: kerberos@mit.edu
> Subject: Credential cache file format documentation
>
> Inspired by Michael B Allen's writeup of the keytab file format posted
> to this list a few months ago, which allowed me to implement support
> for reading keytab's in Shishi, I became interested in documentation
> of the ccache file format.
>
> I didn't find much documentation, but the format was pretty
> straight-forward, so I wrote the following description of it.  If
> someone is looking for the same thing, I'd thought I'd share this.  To
> read it, it probably helps to have read Michael's keytab.txt first.
>
> As you'd might suspect, this is the first step towards reading (and
> possibly writing) ccache files in Shishi...
>
> Enjoy,
> Simon
>
> The Kerberos Credential Cache Binary File Format
> Copyright (C) 2006 Simon Josefsson 
> http://josefsson.org/shishi/ccache.txt
> Last updated: Wed Sep 13 17:11:53 CEST 2006
>
> Like the MIT keytab binary format (see Michael B Allen's reverse
> engineered description in keytab.txt), the credential cache format is
> not standard nor documented anywhere.
>
> In C style notation, the MIT credential cache file format is as
> follows.  All values are in network byte order.  All text is ASCII.
>
> ccache {
>   uint16_t file_format_version; /* 0x0504 */
>   uint16_t taglen;  /* only if version is 0x0504
*/
>   header tags[];/* only if version is 0x0504
*/
>   principal primary_principal;
>   credential credentials[*];
> };
>
> credential {
>principal client;
>principal server;
>keyblock key;
>timestime;
>uint8_t  is_skey;/* 1 if skey, 0 otherwise */
>uint32_t tktflags;
>uint32_t num_address;
>address  addrs[num_address];
> 

RE: Credential cache file format documentation

[Tim Alsop]

Simon,

If you can, it would be useful if you can document the cache type 0x0504
differences, e.g. what the header tag/tags contain, and in what format.
We recently made some changes to our products, and in order to test the
cache interoperability I tried to find documentation on the header tags,
but couldn't. We are also considering adding a new header tag but cannot
do this without understanding if there are any interop issues that this
may cause. I could not find any doc which indicates whether it is
possible to add additional information into a cache header, if cache
type is 0x0504. Do you know whether this is described anywhere ?

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Simon Josefsson
Sent: 13 September 2006 16:44
To: kerberos@mit.edu
Subject: Credential cache file format documentation

Inspired by Michael B Allen's writeup of the keytab file format posted
to this list a few months ago, which allowed me to implement support
for reading keytab's in Shishi, I became interested in documentation
of the ccache file format.

I didn't find much documentation, but the format was pretty
straight-forward, so I wrote the following description of it.  If
someone is looking for the same thing, I'd thought I'd share this.  To
read it, it probably helps to have read Michael's keytab.txt first.

As you'd might suspect, this is the first step towards reading (and
possibly writing) ccache files in Shishi...

Enjoy,
Simon

The Kerberos Credential Cache Binary File Format
Copyright (C) 2006 Simon Josefsson 
http://josefsson.org/shishi/ccache.txt
Last updated: Wed Sep 13 17:11:53 CEST 2006

Like the MIT keytab binary format (see Michael B Allen's reverse
engineered description in keytab.txt), the credential cache format is
not standard nor documented anywhere.

In C style notation, the MIT credential cache file format is as
follows.  All values are in network byte order.  All text is ASCII.

ccache {
  uint16_t file_format_version; /* 0x0504 */
  uint16_t taglen;  /* only if version is 0x0504 */
  header tags[];/* only if version is 0x0504 */
  principal primary_principal;
  credential credentials[*];
};

credential {
   principal client;
   principal server;
   keyblock key;
   timestime;
   uint8_t  is_skey;/* 1 if skey, 0 otherwise */
   uint32_t tktflags;
   uint32_t num_address;
   address  addrs[num_address];
   uint32_t num_authdata;
   authdata authdata[num_authdata];
   countet_octet_string ticket;
   countet_octet_string second_ticket;
};

keyblock {
 uint16_t keytype;
 uint16_t etype;/* only present if version
0x0503 */
 counted_octet_string keyvalue;
};

times {
  uint32_t  authtime;
  uint32_t  starttime;
  uint32_t  endtime;
  uint32_t  renew_till;
};

address {
uint16_t addrtype;
counted_octet_string addrdata;
};

authdata {
 uint16_t authtype;
 counted_octet_string authdata;
};

header {
   uint16_t tag;/* 1 = DeltaTime */
   uint16_t taglen;
   uint8_t tagdata[taglen]
};

DeltaTime {
   uint32_t time_offset;
   uint32_t usec_offset;
};

principal {
  uint32_t name_type; /* not present if version 0x0501 */
  uint32_t num_components;/* sub 1 if version 0x501 */
  counted_octet_string realm;
  counted_octet_string components[num_components];
};

counted_octet_string {
uint32_t length;
uint8_t data[length];
};

Permission to copy, modify, and distribute this document, with or
without modification, for any purpose and without fee or royalty is
hereby granted, provided that you include this copyright notice in ALL
copies of the document or portions thereof, including modifications.

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: kadmin ktadd -e keysaltlist for des-cbc-md5

[Tim Alsop]

Tom,

Using MIT krb5 1.5.1, I tried this :

kadmin.local:  addprinc -randkey test/[EMAIL PROTECTED]
WARNING: no policy specified for test/[EMAIL PROTECTED]; defaulting to no
policy
Principal "test/[EMAIL PROTECTED]" created.
kadmin.local:  ktadd -e DES-CBC-MD5:NORMAL test/princ
Entry for principal test/princ with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin.local:

As you can see, this works fine, and I don't get any errors like you
did.

I then used CyberSafe client to test the principal in KDC is ok ?

I first requested a TGT from the MIT KDC :

# kinit [EMAIL PROTECTED]
Password for [EMAIL PROTECTED]: 
#

Then, using kinit -S I was able to get a service ticket with DES-CBC-MD5
(etype 3) session key using the principal just created. As you can see
below, this works :

# kinit -S test/[EMAIL PROTECTED]
# klist -e
  Cache Type: Kerberos V5 Credentials Cache
  Cache File: /krb5/tmp/cc/krb5cc_0
   Cache Version: 0504
   Default Principal: [EMAIL PROTECTED]

Valid FromExpires   Service
Principal
  
-
Tue 12 Sep 2006 22:52:19 BST  Wed 13 Sep 2006 06:52:19 BST
krbtgt/[EMAIL PROTECTED]
   Session Key EType: 23 (ARCFOUR-HMAC-MD5)
Ticket EType: 23 (ARCFOUR-HMAC-MD5)
Tue 12 Sep 2006 22:52:25 BST  Wed 13 Sep 2006 06:52:19 BST
test/[EMAIL PROTECTED]
   Session Key EType:  1 (DES-CBC-CRC)
Ticket EType:  3 (DES-CBC-MD5)
#

I hope this helps.

Regards,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Simons
Sent: 12 September 2006 22:18
To: kerberos@mit.edu
Subject: kadmin ktadd -e keysaltlist for des-cbc-md5

I'm trying to get a keytab with des-cbc-md5 encryption (no salt) from
our
kerberos 1.5 realm for a CyberSafe client. How do I specify the ktadmin
ktadd command's "-e keysaltlist" parameter?  I tried variations on
"ktadd -k
 -e ENCTYPE_DES_CBC_MD5:NONE", but get the same error:

kadmin:  ktadd -k host.TESTMIT.keytab -e ENCTYPE_DES_CBC_MD5:NOSALT
ktadd: Invalid argument while parsing keysalts ENCTYPE_DES_CBC_MD5

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: unix active directory

[Tim Alsop]

Michael,

I suggest you take a look at XAD (www.padl.com). This is a product that
runs on Linux, and looks like an Active Directory domain controller.

Cheers,
Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Michael B Allen
Sent: 09 August 2006 20:33
To: Shawn Wilson
Cc: kerberos@mit.edu
Subject: Re: unix active directory

Hi Shawn,

Active Directory is the name of Microsoft's KDC/LDAP server. So there's
no such thing as "Active Directory server on linux". You could setup a
KDC (MIT, Heimdal, etc) or an LDAP server (OpenLDAP, Fedora Directory
Server) on your Linux machine but even if you managed to get them
to work together well, you still wouldn't have anything like "Active
Directory". The closest thing to AD on linux would be Samba4 but that's
not quite ready for production environments.

Also, unless you have a specific question about Kerberos I think
responses
here will be limited [1].

Mike

[1] I pleased to see that this list is very tolerant of posts about
"Active Directory". Apparently the OpenLDAP-software list automatically
censors any post containing the term (e.g. my sig).

On Wed, 9 Aug 2006 09:46:47 -0700 (PDT)
Shawn Wilson <[EMAIL PROTECTED]> wrote:

> I am interested in getting an Active Directory server setup on a linux
(Ubuntu)
> server. I currently just have a samba file server, ntp, and dns setup
on this
> server. I don't have any Windows 2k/XP servers here.
> 
> I have found many howtos and other docs on kerberos, ldap, and samba.
However
> my question is where to start. In theory, what I was looking for was a
cookie
> cutter solution to getting an Active Directory server setup on Unix.
However
> aside from that, I was wondering where I should start.
> 
> One more point of woe for me is that I don't have a FQDN. I was
advised that I
> could just make one on my dns and setup dhcp to make sure those hosts
used my
> dns and be fine with that. I was wondering if this is possible?
> 
> Also, though I have googled and have a bit more than a half dozen
pages along
> this topic bookmarked, any resources that anyone could recommend would
be
> appreciated.
> 
> 
> 
> thanx
> darkhaven (aka - shawn wilson / ag4ve)
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 


-- 

Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

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


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

RE: Sybase Installations??: Sybase 12.5, Powerbuilder 8 on Win XP client

[Tim Alsop]

Markus, Herbert,

Corrections to the comments below :

XP desktop 
- You can use MIT or CyberSafe libraries. 
- The main difference is that our libraries are commercially supported,
documented and tested for use with Sybase products.

ODBC
- You can use MIT or CyberSafe libraries.
- The main difference is that our libraries are commercially supported,
documented and tested for use with Sybase products.

Data Direct Driver
- You can use CyberSafe libraries. I don't believe MIT libraries have
been tested by Data Direct.

Isql
- You can use MIT or CyberSafe libraries.
- The main difference is that our libraries are commercially supported,
documented and tested for use with Sybase products.

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Markus Moeller
Sent: 20 May 2006 00:53
To: kerberos@MIT.EDU
Subject: Re: Sybase Installations??: Sybase 12.5,Powerbuilder 8 on Win
XP client

The latest sybase version 12.5.4 come with Kerberos libraries from
cybersafe 
(which I haven't tested). We are using the MIT libraries instead and on
the 
XP desktop you can use the sybase ODBC/OLEDB drivers with SSPI. If you
use 
the data direct driver you have to install MIT Kerberos on the desktop
too. 
To use isql you need the MIT Kerberos libraries too.

Regards
Markus

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
om...
>
> Hi,
>
> We are implementing Kerberos on a Powerbuilder 8 client-server app
(sybase
> 12.5 backend) running on Win XP on the client side. We have read
> documentation on the Sybase website that we need to download Kerberos 
> files
> from MIT website and install them on the Sybase server. However, when
we
> asked around we are hearing that perhaps nothing needs to be done 
> (Kerberos
> is already "installed" on the client desktops as part of Windows).
>
> Can someone please advise us on what (if anything) we need to do on
the
> Sybase server to make it work with Kerberos??
>
> Many thanks in advance!
>
> Herbert
>
>

---
> This message (including any attachments) is confidential and may be
> privileged. If you have received it by mistake please notify the
sender by
> return e-mail and delete this message from your system. Any
unauthorised
> use or dissemination of this message in whole or in part is strictly
> prohibited. Please note that e-mails are susceptible to change. ABN
AMRO
> Bank N.V, which has its seat at Amsterdam, the Netherlands, and is
> registered in the Commercial Register under number 33002587, including
its
> group companies, shall not be liable for the improper or incomplete
> transmission of the information contained in this communication nor
for 
> any
> delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or
its
> group companies) does not guarantee that the integrity of this
> communication has been maintained nor that this communication is free
of
> viruses, interceptions or interference.
>

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



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


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

RE: keytab file format - exporting arcfour keys from active directory

[Tim Alsop]

Yes, you are correct. 

Also, if you display a key table file using ktutil, and you have a
DES-CBC-CRC key, you would see 1. 

Since we see values of 1,3,16,23 etc. in the key table file entry, this
suggests the 'cipher suite' number (commonly known as etype).

>From RFC4120, we see :

   EncryptionKey   ::= SEQUENCE {  
   keytype [0] Int32 -- actually encryption type --, 
   keyvalue[1] OCTET STRING 
   }

The comment in the RFC suggests the keytype field is actually the
encryption type (e.g. etype) and not the keytype ...

Hopefully you can see from my above examples, that use of keytype is a
little confusing and open to interpretation ? I guess this is why the
comment was added in RFC4120 ?

Thanks,
Tim

-Original Message-
From: Michael B Allen [mailto:[EMAIL PROTECTED] 
Sent: 01 May 2006 23:33
To: Tim Alsop
Cc: [EMAIL PROTECTED]; kerberos@mit.edu
Subject: Re: keytab file format - exporting arcfour keys from active
directory

On Mon, 1 May 2006 22:32:44 +0100
"Tim Alsop" <[EMAIL PROTECTED]> wrote:

>  * 0 2  keytype
>  * 2 2  keylen
>  * 4 keylen keydata
>  * }
>  * POSSIBLE if length left {
>  * xxx 4vno
>  * }
>  */
> 
> Is the "keytype" actually the key type, or is it the etype ? I ask
this
> because I have seen key tables created by various products that have
the
> etype stored in this field.

Keytype. At least the values I'm seeing correspond to the values seen
in ktutil list (e.g. 3 is des-cbc-md5, 23 is arcfour-hmac-md5, 16 is
des3-cbc-sha1, etc).

Mike


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

RE: keytab file format - exporting arcfour keys from active directory

[Tim Alsop]

Regarding :

/*
 *
 * keytab format:
 *
 * head:
 * 0 1  5
 * 1 1  VNO 1 or 2
 * per entry:
 * 0 4  len (excludes len)
 * 4 2  count of princ components (pc)
 * 6 2  length realm (rl)
 * 8 rl realm
 * REP *pc {
 *  0 2 length nl
 *  2 nl name-component
 * }
 * IF new? {
 * xxx 4name-type
 * }
 * xxx 4timestamp
 * xxx 1vno
 * {
 * 0 2  keytype
 * 2 2  keylen
 * 4 keylen keydata
 * }
 * POSSIBLE if length left {
 * xxx 4vno
 * }
 */

Is the "keytype" actually the key type, or is it the etype ? I ask this
because I have seen key tables created by various products that have the
etype stored in this field.

Thanks,
Tim


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

RE: Problem with the ktpass.exe with Windows 2003 Server

[Tim Alsop]

Andres,

No keytab file was created because the command 'Aborted'. Normally the file is 
created in the same directory where you ran the command from, or another 
directory if you specify something like -out c:\servidor.keytab

Anyway, did you create a user in your domain called root with a password = 
password ? If so, when you use -mapuser you need to specify -mapuser [EMAIL 
PROTECTED]

Also, make sure you are using the pre-SP1 version of ktpass, rather than the 
version which was upgraded when Win2k3 SP1 was shipped.

Thanks,
Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrés Abadía
Sent: 17 April 2006 08:21
To: [EMAIL PROTECTED]; Kerberos@mit.edu
Subject: Problem with the ktpass.exe with Windows 2003 Server

Hello, i was trying to use the ktpass this way:
   
  ktpass -princ nssldap/[EMAIL PROTECTED] -pass password -mapuser root -out 
servidor.keytab.
   
  and the prompt gave me this message:
   
  Targeting domain controller: servidor.proyectodegrado.com
  Using legacy password setting method
  Succesfully mapped nssldap/servidor to root
  Aborted
   
  but I can`t find the file servidor.keytab because i need this file to merge 
to the unix host.
   
  I need help with this, I don't know if the command ktpass did the process 
correctly and i don't know where is located the file.
   
  thanks for you attention.
   
  Andres Abadia


-

LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com

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


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

RE: Powerbuilder 8, Sybase 12.5, Kerberos

[Tim Alsop]

Herbert,

Please see answers inline below : 

We have a lot of experience of using Kerberos with Sybase ASE, so if you
want any more help after this, can we chat offline ?

Thanks,
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: 13 April 2006 19:29
To: kerberos@mit.edu
Subject: Powerbuilder 8, Sybase 12.5, Kerberos


Hi,

We have a Powerbuilder 8 application with Sybase 12.5 backend. We are
trying to strengthen the application authentication by employing
Kerberos
(talking to Active Directory). We know that Powerbuilder 10 works with
Kerberos, does anyone know whether Powerbuilder 8 would work too?

Tim> Yes, Powerbuilder 8 is able to be used as a client with an ASE 12.5
database server, and Kerberos authentication.

Also:

1) Once we are converted, how would authorization work? As we understand
it, Kerberos would take care of the authentication. However, when the db
requests get to Sybase, how does it know what authority (grants) a
particular user has (we have been told we do not need users defined in
sybase anymore)?

Tim> you have to create users in the database which are then used to
determine authorisation. The Kerberos tickets are used to authenticate
this user so that no passwords need to be transmitted or stored in the
database, but all other permissions associated with the Sybase user are
still present in the database as they are for non-Kerberos authenticated
users.

2) Also, if we "Kerberize" the sybase server, would all db instances in
that server be also "Kerberized"?

Tim> no, only users who are setup for Kerberos authentication.

3) Finally, once we "kerberize" a server/database, would we be able to
logon the the server/db without going through Kerberos (via Isql, etc.)?

Tim> yes, you can logon to database using tools like isql and Kerberos
authentication (for example, if you use isql -V) or if you have a user
with a userid/password in sybase database you can also use this by
specifying the userid and password when running isql.

Thanks


---
This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender
by
return e-mail and delete this message from your system. Any unauthorised
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change. ABN AMRO
Bank N.V, which has its seat at Amsterdam, the Netherlands, and is
registered in the Commercial Register under number 33002587, including
its
group companies, shall not be liable for the improper or incomplete
transmission of the information contained in this communication nor for
any
delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or
its
group companies) does not guarantee that the integrity of this
communication has been maintained nor that this communication is free of
viruses, interceptions or interference.

---


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: kinit request on keytab fails using 2K3sp1 KDC

[Tim Alsop]

David,

I have seen this problem before. It does not occur with the pre-SP1
version of ktpass. Conclusion : If you want to create keytable files
which have correct kvno's and which work correctly with des, then you
must use the pre-SP1 version of ktpass. 

Thanks, Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David Telfer
Sent: 23 March 2006 17:39
To: kerberos@mit.edu
Subject: Re: kinit request on keytab fails using 2K3sp1 KDC

Jeffrey Altman wrote:
> Why do you need the kvno to be 1?  
It wasn't so much that they needed to match, more to tidy up the
situation I had on the KDC.

> For example, what is the enctype of the service ticket issued by the
> KDC?  Does that match the enctype of the keytab entry you are using?
>
> What do the following commands output?
>
>   klist -e -k /etc/krb5.keytab
>
>   kvno HTTP/[EMAIL PROTECTED]
>   klist -e
>   
This appears to be the problem, the keytab is being generated with DES 
CBD MD5, the service principal is sending an ArcFour encrypted tgt.

The reason this never occured to me is that the user account has the 
'use DES encryption for this account' setting ticked.  I have tried the 
following process to force the service principal to be DES;

1 - create account
2 - run ktpass util with -mapop set +DesOnly  and -crypto DES-CBC-MD5 
options set.
3 - view account properites and ensure that 'use DES encryption for this

account' is checked
4 - change password of account (with the intention of forcing the DES 
change from the ktpass step above)
5 - re-run identical ktpass line and use this as the final keytab

Even with these steps, the encryption type of the ServicePrincipal tgt 
stays as ArcFour.

Unfortunately I am not the AD administrator, I have access to an admin 
member of staff who has been applying the changes for me.  Due to this I

cannot be sure of every setting their kdc controller has.  Specifically 
I would be keen to find out whether there is a global setting which 
forces all user and service principals to be created as ArcFour.  Has 
anyone experienced somehing like this, or do they know of a way to hard 
force the enc type of the service principal.
> If the enctypes and output of those commands match, then you must
> double check that the browser client is obtaining service tickets
> with the name HTTP/[EMAIL PROTECTED] and that the
> enctype of that ticket matches the contents of the keytab entry.
>   
I haven't got to the stage of attempting to use mod_auth_kerb yet.  I am

still trying to get past the `#./kinit -k -t /etc/krb5.keytab 
HTTP/[EMAIL PROTECTED] stage.  I may look into the 
potential for using ArcFour for both the keytab and ServicePrincipal but

I'm sure this will open another can of worms as well.

Thanks,
David





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: kinit request on keytab fails using 2K3sp1 KDC

[Tim Alsop]

>From the determined kvno information, I am worried that starting again 
>will not resolve my issue.  Assuming that the kvno is reset to 1, using

>kvno and klist to determine the version number should return similar 
>results to above, but showing the number to be 1.  What would the 
>difference be and would it resolve the pre-authentication issue?

We found that even if we start again, we could not get the pre-auth to
work. 


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

RE: kinit request on keytab fails using 2K3sp1 KDC

[Tim Alsop]

David,

Like yourself we spent many days/weeks trying to get the sp1 version of
ktpass to work, but we could not, so we have developed our own
replacement product that uses computer accounts instead.

Cheers, Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David Telfer
Sent: 23 March 2006 09:47
To: kerberos@mit.edu
Subject: Re: kinit request on keytab fails using 2K3sp1 KDC

Richard E. Silverman wrote:
>
> TA> It seems that the sp1 version of ktpass stores a key with a
> TA> specific kvno in the keytab file, and the kvno in the domain
> TA> controller for the same principal is different. This is why
you
> TA> cannot use the keytab file to authenticate.
>
> Yes; it always sets the kvno in the keytab it writes to 1, regardless
of
> the value in the KDB (which of course changes each time the key is
> extracted).  So, you can only use the keytab the first time you
extract
> it.  If you have to do it again, just delete the principal and
re-create
> it.
I am not sure whether this is the issue or not, I may be doing something

wrong but I have used the following procedure to determine the kvno of 
both the keytab and the service principal.

To determine the KDC principal kvno;

#./kinit HTTP/[EMAIL PROTECTED]
--->prompted for system user password
#./kvno HTTP/[EMAIL PROTECTED]
HTTP/[EMAIL PROTECTED]: kvno = 3

To determine the keytab kvno;

# /usr/local/sbin/ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  list
slot KVNO Principal
  
-
   13   HTTP/[EMAIL PROTECTED]

This is the step I am unsure of, but I believe it indicates that the 
keytab also has a KVNO of 3.  Is this correct?

Also, for each creation of the keytab I am deleting the system user and 
service principal first before creation.  Should this not reset the kvno

back to the initial value?

Thanks,
David Telfer



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: kinit request on keytab fails using 2K3sp1 KDC

[Tim Alsop]

David,

The easiest solution to this problem is to use the ktpass which was
shipped with Windows 2003, and not the one with SP1.

Alternatively, you can use one of the many tools available that replace
the need for ktpass, and use computer accounts for key storage. These
tools do not suffer from the same issues as ktpass.

It seems that the sp1 version of ktpass stores a key with a specific
kvno in the keytab file, and the kvno in the domain controller for the
same principal is different. This is why you cannot use the keytab file
to authenticate.

Thanks, Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David Telfer
Sent: 22 March 2006 17:09
To: kerberos@mit.edu
Subject: kinit request on keytab fails using 2K3sp1 KDC

Hello,

I am testing a keytab obtained from a Windows 2003 Server (sp1) prior to

configuring mod_auth_kerb.  I have used the following command to 
generate a keytab on the KDC;
ktpass -mapuser [EMAIL PROTECTED] -princ 
HTTP/[EMAIL PROTECTED] +DesOnly -pass userspassword -ptype 
KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 -out "c:\krb5.keytab"

The *nix server is running Solaris 9 with MIT krb5-1.4.3.  I have 
transfered the keytab to /etc/krb5.keytab.  When I run ;
#/usr/local/bin/kinit -k -t /etc/krb5.keytab 
HTTP/[EMAIL PROTECTED]

I get the following error;
kinit(v5): Preauthentication failed while getting initial credentials

I am able to obtain a ticket directly from the kdc using #./kinit 
[EMAIL PROTECTED] which would indicate that the problem wasn't a 
clock slew error (I haven't seen an error of this nature appear with 
this version of krb so I'm not sure whether it would explicitly state
this).

 From reading a few mailing list posts I have discovered some people 
having issues with ktpass on service pack 1.  One such post;
http://groups.google.com/group/comp.protocols.kerberos/browse_thread/thr
ead/1c991fa1b6ea4ef8/3da9428688c66d72%233da9428688c66d72
details a similar problem  I have followed the advice given, ensuring 
that the kvno's match and changing the system users password prior to 
generating the keytab but to no avail.

My /etc/krb5.conf file is as follows (I've removed every non-essential 
entry to ensure that it isn't the issue);

[libdefaults]
default_realm = SMG.PLC.UK
[domain_realm]
connect.smg.plc.uk = SMG.PLC.UK
[realms]
SMG.PLC.UK = {
kdc = pqdomc01.smg.plc.uk
admin_server = pqdomc01.smg.plc.uk
default_domain = smg.plc.uk
}

Has anyone experienced a similar problem to this?  I have to assume 
there is a problem with the keytab but I'm at a loss as to what the 
problem could be.

David Telfer
[EMAIL PROTECTED]





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: Oracle Advanced Security Option and Kerberos

[Tim Alsop]

Douglas,

In Oracle 10, Oracle decided to remove the GSS functionality (i.e. The
CyberSafe adapter), and just maintain 1 adapter - namely the MIT
Kerberos adapter, which they took time to make some improvements to at
the same time, based on what they previously had in Oracle 9. Clearly it
has a long way to go still, and it would be worth them removing it,
going back to the GSS adapter, thus providing the capabililies that
customers are asking for without them having to support (or not ?) their
own Kerberos implementation.

We have customers using our products with Oracle 9, and these customers
cannot upgrade to Oracle 10 due to the fact that the GSS adapter has
been removed, so I have a desire to help you with this, hoping that our
customers will then be able to continue to enjoy the benefits of our
commercially supported product and also be able to upgrade to a new
Oracle version.

I doubt that threatening to use Sybase or IBM's database will help,
unless you are Oracle's biggest customer :-)

Please feel free to pass on my email to Oracle.

The product manager I talked with previously was Sudha Iyer. I prepared
a presentation for here, trying to explain why they should not 'take a
step backwards' with Oracle 10, but it didn't work :-( I believe Sudha
is still with Oracle, but is not involved with ASO anymore.

Thanks, Tim

-Original Message-
From: Douglas E. Engert [mailto:[EMAIL PROTECTED] 
Sent: 24 February 2006 20:50
To: Tim Alsop
Cc: kerberos@mit.edu
Subject: Re: Oracle Advanced Security Option and Kerberos

Thanks, Tim, this does explain a lot, and I like the gssapi plugin
approach. We need to try and get Oracle to do this.

Tim Alsop wrote:

> Douglas,
> 
> Some more info for you :
> 
> In Oracle 7,8 and 9 there are 2 ASO adapters, one called "KERBEROS5"
and
> the other called "CYBERSAFE". You can determine which adapter is used
> when you configure sqlnet.

What about 10? In the Netmanager? On windows, I only see KERBEROS5, NTS
and RADIUS as choices. Does it have to have CyberSafe installed before
it will show it?

> 
> The CyberSafe ASO Kerberos adapter uses GSSAPI. This is because we
don't
> expose our native K5 protocol API to partners, or to any customers,
and
> also (perhaps more importantly) it allows the CyberSafe Kerberos
product
> installed to be changed/updated without having to install a new Oracle
> database/client. In this case, the GSSAPI library takes care of
> interfaces with the cred cache, additional protocols, KDC differences
> etc. 

Yes, that would solve many of the the problems, like more DES only,
the KRB5CCNAME parsing, and ticket cache type.

> 
> The other ASO adapter called KERBEROS5 is implemented by Oracle, using
> an old version of MIT Kerberos code which is embedded inside the
Oracle
> product, so you don't have to install any Kerberos libraries yourself.

Doing an nm on the library, and looking at routine names. it does not
look like any MIT release I have even seen. That was why I was
speculating
that it was from your product.

> This has many disadvantages because you cannot update the MIT code to
> the latest version, and have to rely on Oracle updating their code,
> which they did when they moved to Oracle 10.
> 

Yes, the DES only, cache type = 2  and KRB5CCNAME parsing are good
examples
of where this had an effect.


> I hope you will agree, that the more appropriate architecture moving
> forwards would be to use GSSAPI, and have some sort of configuration
> parameter in sqlnet, so that the GSS library name can be specified.
This
> will mean customers can use any GSSAPI library with Oracle software,
> apply their own mods, updates etc. without (a) waiting for Oracle to
> make same changes, and (b) installing a new version of Oracle just so
> they can improve security. Of course, it will also mean that Oracle
> won't need to 'embed' any Kerberos libraries in their product, and
this
> will make supporting new customer requirements much easier than it is
> today. This is the approach used by Sybase and IBM with database
> products - both of them support Kerberos using a configurable GSS-API
> library.

I full agree! You say Sybase and IBM do this... That might be an option
if Oracle does not make some improvements.


> I talked to Oracle about 3 years ago, suggesting that they made
> these changes, but the product manager at that time was not able to
> convince others in Oracle development team that this was the 'way to
> go'.

I think a lot of people have talked to Oracle, over the years, and get
the same response...

> Maybe you will have more luck if you try again ?

Thats what this threadis all about.

> 
> I agree that the mapping needs to be improved. Our experience is that
> customers have difficultly with the way it works today because the

RE: Oracle Advanced Security Option and Kerberos

[Tim Alsop]

Douglas,

Some more info for you :

In Oracle 7,8 and 9 there are 2 ASO adapters, one called "KERBEROS5" and
the other called "CYBERSAFE". You can determine which adapter is used
when you configure sqlnet.

The CyberSafe ASO Kerberos adapter uses GSSAPI. This is because we don't
expose our native K5 protocol API to partners, or to any customers, and
also (perhaps more importantly) it allows the CyberSafe Kerberos product
installed to be changed/updated without having to install a new Oracle
database/client. In this case, the GSSAPI library takes care of
interfaces with the cred cache, additional protocols, KDC differences
etc. 

The other ASO adapter called KERBEROS5 is implemented by Oracle, using
an old version of MIT Kerberos code which is embedded inside the Oracle
product, so you don't have to install any Kerberos libraries yourself.
This has many disadvantages because you cannot update the MIT code to
the latest version, and have to rely on Oracle updating their code,
which they did when they moved to Oracle 10.

I hope you will agree, that the more appropriate architecture moving
forwards would be to use GSSAPI, and have some sort of configuration
parameter in sqlnet, so that the GSS library name can be specified. This
will mean customers can use any GSSAPI library with Oracle software,
apply their own mods, updates etc. without (a) waiting for Oracle to
make same changes, and (b) installing a new version of Oracle just so
they can improve security. Of course, it will also mean that Oracle
won't need to 'embed' any Kerberos libraries in their product, and this
will make supporting new customer requirements much easier than it is
today. This is the approach used by Sybase and IBM with database
products - both of them support Kerberos using a configurable GSS-API
library. I talked to Oracle about 3 years ago, suggesting that they made
these changes, but the product manager at that time was not able to
convince others in Oracle development team that this was the 'way to
go'. Maybe you will have more luck if you try again ?

I agree that the mapping needs to be improved. Our experience is that
customers have difficultly with the way it works today because they
cannot use existing database users, instead they have to create new
users using the realm name as part of the username, and it has to be
uppercase. This means, that a Kerberos principal [EMAIL PROTECTED] and a
principal [EMAIL PROTECTED] would have their own unique passwords, but Oracle
would authenticate them both as [EMAIL PROTECTED] (the Oracle username) even
though they are different principals with different passwords :-)

I hope this helps ?

Thanks, 
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Douglas E. Engert
Sent: 24 February 2006 16:16
To: kerberos@mit.edu
Subject: Oracle Advanced Security Option and Kerberos


Oracle has had Kerberos support for about 10 years via the Oracle
Advanced
Security Option (ASO) formally know as Oracle Advanced Networking
Option.
There are a lot of articles from 1998-2003 on using the ASO but very
little after.

A few simple changes could vastly improve the usability of the ASO.

The code appears to not have been kept up to date, as it only does
single DES,
and uses a type 2 ticket cache. But some selective features have been
made,
including TCP support for the KDC, and on a Windows box, the client can
use
the Microsoft ticket cache (and maybe SSPI) to the server on Unix using
GSSAPI.
It can delegate credentials to the server so one database server can
authenticate to another as the user. Yet it has a simple bug with
parsing
of the KRB5CCNAME variable.

It is not clear what Kerberos code base is used, as the libs don't match
the MIT or Heimdal.  Articles refer to CyberSafe Trust Broker
interoperability
so it may be CyberSafe.

The ASO uses the full principal name with realm as the Oracle username
without
any mapping from principal to Oracle username. The name is also limited
to 30
characters. The lack of a mapping makes it very difficult to add
Kerberos support
to an existing database.




I am looking for other Kerberos sites that use Oracle with or without
the ASO
who would like to see the ASO improved. I would also be interested to
know if
you have approached Oracle on improvements, and what was their response.

Personally I believe there has been a lot of customer interest in
improvements
especially from the security people, but this may not have been
communicated
to Oracle by the DBAs that deal with Oracle. Or if it has, Oracle has
not been
able to see the big picture, and thus not much has changed in the last
few years.


-- 

  Douglas E. Engert  <[EMAIL PROTECTED]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

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



_

RE: Oracle Advanced Security Option and Kerberos

[Tim Alsop]

Douglas,

Some more info for you :

In Oracle 7,8 and 9 there are 2 ASO adapters, one called "KERBEROS5" and
the other called "CYBERSAFE". You can determine which adapter is used
when you configure sqlnet.

The CyberSafe ASO Kerberos adapter uses GSSAPI. This is because we don't
expose our native K5 protocol API to partners, or to any customers, and
also (perhaps more importantly) it allows the CyberSafe Kerberos product
installed to be changed/updated without having to install a new Oracle
database/client. In this case, the GSSAPI library takes care of
interfaces with the cred cache, additional protocols, KDC differences
etc. 

The other ASO adapter called KERBEROS5 is implemented by Oracle, using
an old version of MIT Kerberos code which is embedded inside the Oracle
product, so you don't have to install any Kerberos libraries yourself.
This has many disadvantages because you cannot update the MIT code to
the latest version, and have to rely on Oracle updating their code,
which they did when they moved to Oracle 10.

I hope you will agree, that the more appropriate architecture moving
forwards would be to use GSSAPI, and have some sort of configuration
parameter in sqlnet, so that the GSS library name can be specified. This
will mean customers can use any GSSAPI library with Oracle software,
apply their own mods, updates etc. without (a) waiting for Oracle to
make same changes, and (b) installing a new version of Oracle just so
they can improve security. Of course, it will also mean that Oracle
won't need to 'embed' any Kerberos libraries in their product, and this
will make supporting new customer requirements much easier than it is
today. This is the approach used by Sybase and IBM with database
products - both of them support Kerberos using a configurable GSS-API
library. I talked to Oracle about 3 years ago, suggesting that they made
these changes, but the product manager at that time was not able to
convince others in Oracle development team that this was the 'way to
go'. Maybe you will have more luck if you try again ?

I agree that the mapping needs to be improved. Our experience is that
customers have difficultly with the way it works today because they
cannot use existing database users, instead they have to create new
users using the realm name as part of the username, and it has to be
uppercase. This means, that a Kerberos principal [EMAIL PROTECTED] and a
principal [EMAIL PROTECTED] would have their own unique passwords, but Oracle
would authenticate them both as [EMAIL PROTECTED] (the Oracle username) even
though they are different principals with different passwords :-)

I hope this helps ?

Thanks, 
Tim

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Douglas E. Engert
Sent: 24 February 2006 16:16
To: kerberos@mit.edu
Subject: Oracle Advanced Security Option and Kerberos


Oracle has had Kerberos support for about 10 years via the Oracle
Advanced
Security Option (ASO) formally know as Oracle Advanced Networking
Option.
There are a lot of articles from 1998-2003 on using the ASO but very
little after.

A few simple changes could vastly improve the usability of the ASO.

The code appears to not have been kept up to date, as it only does
single DES,
and uses a type 2 ticket cache. But some selective features have been
made,
including TCP support for the KDC, and on a Windows box, the client can
use
the Microsoft ticket cache (and maybe SSPI) to the server on Unix using
GSSAPI.
It can delegate credentials to the server so one database server can
authenticate to another as the user. Yet it has a simple bug with
parsing
of the KRB5CCNAME variable.

It is not clear what Kerberos code base is used, as the libs don't match
the MIT or Heimdal.  Articles refer to CyberSafe Trust Broker
interoperability
so it may be CyberSafe.

The ASO uses the full principal name with realm as the Oracle username
without
any mapping from principal to Oracle username. The name is also limited
to 30
characters. The lack of a mapping makes it very difficult to add
Kerberos support
to an existing database.




I am looking for other Kerberos sites that use Oracle with or without
the ASO
who would like to see the ASO improved. I would also be interested to
know if
you have approached Oracle on improvements, and what was their response.

Personally I believe there has been a lot of customer interest in
improvements
especially from the security people, but this may not have been
communicated
to Oracle by the DBAs that deal with Oracle. Or if it has, Oracle has
not been
able to see the big picture, and thus not much has changed in the last
few years.


-- 

  Douglas E. Engert  <[EMAIL PROTECTED]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

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



_

RE: Kerberos and Microsoft products ?

[Tim Alsop]

Ronnie,

Thankyou for your email, and I would also like to thank others who
responded to this question.

I conclude that the company which told me about 'Microsoft moving away
from Kerberos in their future products' must have missunderstood the
response from Microsoft, or the Microsoft employee involved
missunderstood the question asked by the customer ? Maybe Microsoft said
something like "We are moving away from userid+password based
authentication of users, which is implemented using Kerberos, in favour
of two-factor authentication". This could, be missinterpreted to mean
that Kerberos was not going to be used anymore, but in fact this is not
the case, and the answer might have been better qualified to avoid this
confusion ... I can understand how somebody who has limited technical
awareness of Kerberos and MS usage of it, can get confused if they enter
into a discussion about this subject. It is clear that Kerberos in
Microsoft products is 'here to stay' in future products, but will be
used in combination with other related, and complimentary standards,
such as PKINIT, and possibly other standards as they become available in
the future.

Thanks again,

Tim

-Original Message-
From: ronnie sahlberg [mailto:[EMAIL PROTECTED] 
Sent: 21 October 2005 23:32
To: Tim Alsop
Cc: kerberos@mit.edu
Subject: Re: Kerberos and Microsoft products ?

I do not think that is correct.

I am certain that they will use kerberoshowever it is in my
opinion very likely that they will change their kerberos
infrastructure to rely significantly on
digital certificates and the new pkinit draft/standard instead of user
passwords and preauthentication.

I.e.   they will probably make changes to kerberos  but not get rid of
kerberos  instead they will use pkinit+kerberos.

Speculation:
I would not be surprised if they also do things like stuff the PAC
inside the pkinit fields/certificate instead of inside the
authorization data fields and if they also modify the kdc to take the
PAC and other autorization data from within the AS-REQ and put it
inside the krbtgt ticket it sends back   and that the client in
further tgs-req and also ap-req also contains a copy of that data.

It would provide an interesting side channel where they could provide
authorization data from the certificate all the way to the AP-REQ sent
to a service.

I bet there are very interesting features that such a mechanism would
provide.

(at elast that is what i would do instead of only using pkinit as a
vehicle for pre authentication)



On 10/21/05, Tim Alsop <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have just been told by a company (name of company is anonymous) that
> they were recently told by Microsoft, that in the next version of
> Windows, Kerberos will be removed and replaced by something else
> instead. This suggests that Active Directory will no longer be a
> Kerberos server, and Windows will not use Kerberos to authenticate
users
> to domain controllers ?
>
> My question is, has anybody else been told the same ? Is this a
> missunderstanding, or based on fact ?
>
> Thanks, Tim
>
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>




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

Kerberos and Microsoft products ?

[Tim Alsop]

Hi,
 
I have just been told by a company (name of company is anonymous) that
they were recently told by Microsoft, that in the next version of
Windows, Kerberos will be removed and replaced by something else
instead. This suggests that Active Directory will no longer be a
Kerberos server, and Windows will not use Kerberos to authenticate users
to domain controllers ?
 
My question is, has anybody else been told the same ? Is this a
missunderstanding, or based on fact ?
 
Thanks, Tim
 

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

PeopleSoft / Kerberos

[Tim Alsop]

Hi,
 
Does anybody have any experience of Kerberos enabling Peoplesoft 8 so
that credentials obtained at workstation from initial logon to MS AD
domain can be used to authenticate the user to the Peoplesoft
application server (3rd tier) ?
 
If so, can you share with me how you did it, and any gotchas ?
 
Thanks, 
Tim

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

RE: EAP-Kerberos

[Tim Alsop]

Thomas,

Perhaps you need to look at the solution implemented by Symbol
(www.symbol.com). Their WLAN products already use kerberos for WLAN
authentication and key management as an alternative to WEP. The normal
approach with WEP is to share a secret between the AP and WLAN client,
but with Kerberos the session key can be used instead. The WLAN
connection to the network through the access point should not be
accepted until the user has authenticated to the AP. This is the Symbol
approach, but they are not using EAP. Instead they have implemented
Kerberos in the firmware of their products. I would love to see Kerberos
implemented for same solution using EAP-GSS so that more WLAN vendors
can take advantage and gain SSO and strong key management for WLAN
authentication.

Regards, Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Otto
Sent: 14 July 2005 22:44
To: kerberos@mit.edu
Subject: EAP-Kerberos

Hi Chris, Saber, Sam, all,

(sth went wrong with my first email, I try it again)


I read your discussion in the Kerberos Mailing List regarding Kerberos
for Wireless Authentication (June 2005). In February 05, I already
thought a little bit about using Kerberos as single logon for both
* gaining access to a wireless network and
* using the offered kerberized services, so that I began writing an EAP
method which uses Kerberos, (the draft is at
http://www-public.tu-bs.de:8080/~y0013790/ , but so dramatically
immature that it is not worth to be read ;-).

There are generally two ways how to apply Kerberos to WLAN
authentication: 

1) The user has nothing but his username/password. The EAP- conversation
is carried out in order to authenticate at the AS and to get a TGT. 
>From this point, the client uses this TGT to request the TGS
for service tickets. 

2) The user has already network access and a TGT. In this case, the
authenticator (access point) is a service, so that the goal is to get a
service ticket for the service "access point, wireless network access".
Therefore, a proxy Kerberos Server is inside the access point and talks
EAP to the client, and talks in the other direction over IP with the
Kerberos TGS. (I think this is covered by an older proposal, EAP-GSS).

Case 1 is interesting. It would be nice if a user types only once,
namely at the initial logon, his username password, and subsequently get
access to the network and the therein advertised services. 

Is this situation realistic? 

Where could one use Kerberos in wireless authentication otherwise?

I'd be glad if you tell me your ideas, and especially if you see the
need for an EAP Kerberos method. 

Best regards,
Thomas


PS. I'm aware of the property catalogue for an EAP method, which is
intended to be used in wireless networks (
http://www.ietf.org/rfc/rfc4017.txt ).
The major issue is the dictionary attack problem, but I think it could
be mitigated by using some strong password protocol (like the paper of
Wu it proposes).


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: account name case + win2k3 sp1?

[Tim Alsop]

Douglas,

Thank you. Changing the password for the account in domain that was not
working fixed the problem, now with both domains the case of the account
name entered during logon is not used to construct the client principal
name ... Hurray !

Thanks again,

Tim 

-Original Message-
From: Douglas E. Engert [mailto:[EMAIL PROTECTED] 
Sent: 06 July 2005 23:36
To: Tim Alsop
Cc: kerberos@mit.edu
Subject: Re: account name case + win2k3 sp1?



Tim Alsop wrote:

> Hi,
>  
> We have previously observed, that when MS AD is running on Windows 
> 2000 or 2003, when an account has the DES key flag set, the client 
> principal name in cred cache on an XP workstation, after user logon is

> based on the case of the name entered at logon screen, rather than 
> using the case of the account's SAMAccountName attribute + the domain 
> name (in
> uppercase) from AD directory. We were also aware that when no DES key 
> flag was set on an account the correct behaiviour was observed, such 
> that the principal name case was based on the case used to create the 
> account in AD, and the case of the userid entered on XP logon screen 
> was ignored. For example, a user logs onto their workstation, and 
> enters USeRname into the account field, and enters the appropriate 
> password, then after logon their ticket cache shows their tgt client 
> principal name as [EMAIL PROTECTED] This is the desired behaiviour 
> because the tgt principal name should not be based on the case of 
> account name entered when user logs on. We accept that there is an 
> issue when DES flag, and this was confirmed by MS as a bug, but MS 
> have no desire to fix this. We are 100% happy with this.
>  
> However, recently we discovered an issue when Windows 2003 SP1 Active 
> Directory is used. In this environment we are finding that the case of

> the userid entered at the workstation during logon is used to 
> determine the client principal name case (even if an account doesn' t 
> have the DES flag set on) rather than using a consistent case, based 
> on SAMAccountName (which is what we observed before when using AD on 
> Windows 2003 before SP1 was installed).
>  
> To make the situation even stranger, we tried with another Windows 
> 2003
> SP1 domain, and we are finding it is working as expected, so is there 
> an issue with the way SP1 is installed, or perhaps a registry setting 
> we need to be aware of that is different on our 2 domains ?
>  
> Does anybody observe the same ? if so, do you know whether there is a 
> specific fix in SP1 which we can remove to make this work as it did 
> prior to SP1 ?
>  

We ran into a similar problem with Java and mixed case account names.
This had to do with pre_auth and the salt. The Java code assumed it knew
the correct salt, and pre_auth type i.e. using the principal name as
typed by the user and tried to bypass the initial AS_REQ.
The KDC would then return KDC_ERR_PREAUTH_FAILED, assuming it had
previously sent the salt to the user with the KDC_ERR_PREAUTH_REQUIRED.

So is pre_auth_required set the same on both domains?

Has the case of the principals changed without changing the passwords?
i.e. the salt needs to remain the same even if the principal name
changes.

What does ethereal show in the AS_REQ, AS_REP and KRB_ERROR packets?

(Our approach was to say principals are all lower case, and we changed
the few mixed case names and had the passwords reset at the same time.)


> Thanks, Tim
>  
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <[EMAIL PROTECTED]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




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

account name case + win2k3 sp1?

[Tim Alsop]

Hi,
 
We have previously observed, that when MS AD is running on Windows 2000
or 2003, when an account has the DES key flag set, the client principal
name in cred cache on an XP workstation, after user logon is based on
the case of the name entered at logon screen, rather than using the case
of the account's SAMAccountName attribute + the domain name (in
uppercase) from AD directory. We were also aware that when no DES key
flag was set on an account the correct behaiviour was observed, such
that the principal name case was based on the case used to create the
account in AD, and the case of the userid entered on XP logon screen was
ignored. For example, a user logs onto their workstation, and enters
USeRname into the account field, and enters the appropriate password,
then after logon their ticket cache shows their tgt client principal
name as [EMAIL PROTECTED] This is the desired behaiviour because the tgt
principal name should not be based on the case of account name entered
when user logs on. We accept that there is an issue when DES flag, and
this was confirmed by MS as a bug, but MS have no desire to fix this. We
are 100% happy with this.
 
However, recently we discovered an issue when Windows 2003 SP1 Active
Directory is used. In this environment we are finding that the case of
the userid entered at the workstation during logon is used to determine
the client principal name case (even if an account doesn' t have the DES
flag set on) rather than using a consistent case, based on
SAMAccountName (which is what we observed before when using AD on
Windows 2003 before SP1 was installed). 
 
To make the situation even stranger, we tried with another Windows 2003
SP1 domain, and we are finding it is working as expected, so is there an
issue with the way SP1 is installed, or perhaps a registry setting we
need to be aware of that is different on our 2 domains ?
 
Does anybody observe the same ? if so, do you know whether there is a
specific fix in SP1 which we can remove to make this work as it did
prior to SP1 ?
 
Thanks, Tim
 

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

RE: Denial of service when using Active Directory for KDC ?

[Tim Alsop]

Markus,
 
Thankyou. This works for us now. I appreciate your help.
 
Regards, Tim



From: Markus Moeller [mailto:[EMAIL PROTECTED]
Sent: Fri 06/05/2005 10:20
To: Markus Moeller; Tim Alsop; jpbermejo
Cc: kerberos@mit.edu
Subject: Re: Denial of service when using Active Directory for KDC ?




To use a computer account in AD for a principal you have to create first a 
normal
computer account (e.g. mmtest) and execute then:


C:\program files\Support Tools>ktpass  -out d:\Temp\test1.keytab -pass
Test000$ -crypto rc4-hmac-nt /ptype KRB5_NT_SRV_HST -princ te
stsvc/[EMAIL PROTECTED] -mapuser [EMAIL PROTECTED]
Targeting domain controller: testkdc.test.com
Using legacy password setting method
Successfully mapped testsvc/moelma.wks.uk.deuba.com to MMTEST$.
WARNING: Account MMTEST$ is not a user account (uacflags=0x1021).
WARNING: Resetting MMTEST$'s password may cause authentication problems if
MMTEST$ is being used as a server.

Reset MMTEST$'s password [y/n]?  y
Key created.
Output keytab to d:\Temp\test1.keytab:
Keytab version: 0x502
keysize 81 testsvc/[EMAIL PROTECTED] ptype 3 (KRB5_NT_SRV_HST) vno
1 etype 0x17 (RC4-HMAC) keylength 16 (0x5443b0c1ad573155fa2d95eee1971574)


This will create a keytab with a RC4 key which is mapped to a computer account.
Any password expiry set for user accounts (e.g. domain wide settings) won't
affect the computer account.

Regards
Markus






On Fri May  6  9:34 , jpbermejo <[EMAIL PROTECTED]> sent:

>On Thu, 2005-05-05 at 21:52 +0100, Markus Moeller wrote:
>> Tim,
>> in our setup we use computer accounts instead of user accounts, and don't
>> have experienced this issue. I think the latest ktpass can do this with
>> mapuser having a $ at the end.
>
>I don't know about computer accounts, but this DoS is not possible if
>you are using service principals. Active Directory doesn't allow login
>for service principals, and keytab are only useful to decrypt tickets.
>Making an ldap query to AD, you can get things like
>
>dNSHostName: sist03lnx.domain.com
>userPrincipalName: HOST/[EMAIL PROTECTED]
>servicePrincipalName: HTTP/sist03lnx.domain.com
>servicePrincipalName: HTTP/sist03lnx
>
>In this case, only HOST/sist03lnx keytab works with `kinit -k`. If you
>attempt to get a TGT with the other principals, you get nothing.
>
>Javier Palacios
>
>
>
>This e-mail message and any attached files are intended SOLELY for the
addressee/s identified
>herein. It may contain CONFIDENTIAL and/or LEGALLY PRIVILEGED information and
may not
> necessarily represent the opinion of this company. If you receive this message
in ERROR,
>please immediately notify the sender and DELETE it since you ARE NOT AUTHORIZED
to use,
> disclose, distribute, print or copy all or part of the contained information.
Thank you.
>
>
>




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

RE: Denial of service when using Active Directory for KDC ?

[Tim Alsop]

Javier,
 
Thank you again. I understand that the use of computer accounts either with 
ktpass or via another tool (our longer term goal) is the best approach. I am 
exchanging emails with Markus to find out how to use ktpass (short term 
solution) for computer account creation. I am yet to try his latest suggestion. 
 
We will eventually build a netjoin based utility, which will run on each system 
instead of on the domain controller. This will be similar to the code you refer 
to from CSS or provided with Samba, but will be supported by us for our 
customers to use with our products.
 
Regards, Tim



From: jpbermejo [mailto:[EMAIL PROTECTED]
Sent: Fri 06/05/2005 10:59
To: Tim Alsop
Cc: Markus Moeller; kerberos@mit.edu
Subject: RE: Denial of service when using Active Directory for KDC ?



On Fri, 2005-05-06 at 11:28 +0200, Tim Alsop wrote:
> Javier,
>
> Thankyou. I have a related question for your :
>
> In order to use a user account which is then used to run ktpass
> against I need to first create the user account (e.g.

I did use that method many months ago, with a 2000 domain. Now, with a
2003 domain I've actually never tried ktpass seriously, and I use either
samba or css_adkadmin. The first one forces node.domain.com into node$
as principal name, where the second allows HOST/node.domain.com. Both
are standar computer accounts as any other windows machine.
You can get a TGT (or any other tickets) for these principals using the
proper keytab.

> If I understand it correctly the principal name given when ktpass is
> run is used as an alias, but the account in AD can still be accessed
> using the [EMAIL PROTECTED] format ?

As I don't use ktpass anymore, no alias or mapping to user accounts is
performed. With both samba and adkadmin you can create service
principals, and those are again pure windows service principals (as, for
example LDAP/your.domain.controller). Those principals, at least on the
unix side, are not allowed to acquire tickets (neither tgt nor service
ones), so they cannot be 'denialed' anyway as the keytab is only used to
decrypt tickets from other requesting principals.

Javier Palacios




This e-mail message and any attached files are intended SOLELY for the 
addressee/s identified
herein. It may contain CONFIDENTIAL and/or LEGALLY PRIVILEGED information and 
may not
 necessarily represent the opinion of this company. If you receive this message 
in ERROR,
please immediately notify the sender and DELETE it since you ARE NOT AUTHORIZED 
to use,
 disclose, distribute, print or copy all or part of the contained information. 
Thank you.






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

RE: Denial of service when using Active Directory for KDC ?

[Tim Alsop]

Javier,
 
Thankyou. I have a related question for your :
 
In order to use a user account which is then used to run ktpass against I need 
to first create the user account (e.g. [EMAIL PROTECTED]). When I use ktpass I 
specify the name of this account using the -mapuser parameter. 
 
With the above in consideration, surely it is possible to use kinit, or windows 
logon, or some other authentication method to logon as [EMAIL PROTECTED] and 
cause this account to get locked when password attempt is wrong > x times ?
 
If I understand it correctly the principal name given when ktpass is run is 
used as an alias, but the account in AD can still be accessed using the [EMAIL 
PROTECTED] format ?
 
I look forward to your feedback.
 
Regards, Tim



From: jpbermejo [mailto:[EMAIL PROTECTED]
Sent: Fri 06/05/2005 09:34
To: Markus Moeller; Tim Alsop
Cc: kerberos@mit.edu
Subject: Re: Denial of service when using Active Directory for KDC ?



On Thu, 2005-05-05 at 21:52 +0100, Markus Moeller wrote:
> Tim,
> in our setup we use computer accounts instead of user accounts, and don't
> have experienced this issue. I think the latest ktpass can do this with
> mapuser having a $ at the end.

I don't know about computer accounts, but this DoS is not possible if
you are using service principals. Active Directory doesn't allow login
for service principals, and keytab are only useful to decrypt tickets.
Making an ldap query to AD, you can get things like

dNSHostName: sist03lnx.domain.com
userPrincipalName: HOST/[EMAIL PROTECTED]
servicePrincipalName: HTTP/sist03lnx.domain.com
servicePrincipalName: HTTP/sist03lnx

In this case, only HOST/sist03lnx keytab works with `kinit -k`. If you
attempt to get a TGT with the other principals, you get nothing.

Javier Palacios



This e-mail message and any attached files are intended SOLELY for the 
addressee/s identified
herein. It may contain CONFIDENTIAL and/or LEGALLY PRIVILEGED information and 
may not
 necessarily represent the opinion of this company. If you receive this message 
in ERROR,
please immediately notify the sender and DELETE it since you ARE NOT AUTHORIZED 
to use,
 disclose, distribute, print or copy all or part of the contained information. 
Thank you.






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

Denial of service when using Active Directory for KDC ?

[Tim Alsop]

Hi,
 
I wondered if anybody has any experience of this potential DoS issue :
 
- It is common, when using Active Directory as a KDC for user accounts
to be used when creating service principals, and using the Microsoft
ktpass.exe utility to create a key table file.
 
- It is also possible to configure Active Directory so that when a user
gets their password wrong more than a specific number of times their
account is locked until an administrator unlocks them.
 
- If somebody tries to logon (deliberately, or by mistake) using an
account which is being used for a service principal, and gets the
password wrong many times, we assume that the account will be locked in
the same way as a normal user account would be locked. 
 
- If an account gets locked and it is being used for a service
principal, how does Active Directory handle this ? Does it still issue
service tickets for the principal when it receives a TGS request ? Is
there any special logic in AD so that accounts being used in this way
are not locked ?
 
We plan to do some tests to understand what effect this might have, and
whether there is cause for concern, but I wanted to first see if anybody
else has come across this potential DoS, or has any ideas ?
 
Any feedback welcome.
 
Take care,
 
Tim

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

RE: Getting single DES TGT[was Re: KDC: upgrade to 3DES]

[Tim Alsop]

If you use the CyberSafe adapter (also included in Oracle 8i and 9i) -
this adapter uses GSS-API and calls our library, which supports 3DES.

It looks like you have noticed that the Oracle ASO 'Kerberos' adapter
includes Kerberos code based on an old release of MIT libraries.
However, the 'CyberSafe' adapter included in ASO uses GSS-API, which
means the GSS-API/Kerberos library can be updated to support new ciphers
when available without effecting the Oracle software deployment - a much
better architecture, I am sure you will agree ?

Regards,

Tim Alsop
CyberSafe Limited 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Craig Huckabee
Sent: 07 April 2005 22:14
To: kerberos@mit.edu
Subject: Getting single DES TGT[was Re: KDC: upgrade to 3DES]

Hi all,

   I saw this discussion on krb-dev on moving to 3DES support and wanted
to ask a similar question (hopefully more appropriately on this list).

   We're trying to use the Advanced Security Option in Oracle 9.x/10.x
to enable Kerberos authentication - unfortunately, they don't support
3DES keys yet and won't for the near future.  Our KDC is MIT 1.3.6
running on Linux.

   I've been trying to force clients to ask only for des-cbc-crc TGTs,
but haven't been able to do so.  A getprinc on the krbtgt principal for
my realm looks like:

Key: vno 3, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 3, DES cbc mode with CRC-32, no salt
Key: vno 3, DES cbc mode with CRC-32, Version 4

But even when I set:

   default_tgs_enctypes = des-cbc-crc
   default_tkt_enctypes = des-cbc-crc

on the client, I get a des-cbc-crc session key, but a 3des tkt.  This
happens with an MIT 1.3.6 kinit on Linux and Solaris.

   Is the KDC just picking the first key type from the list of available
encryption types, despite what the client asks for ?  Any suggestions
for testing this theory (I've done some ethereal sniffs which lead me to
think the KDC is at fault)?

   Help, advice, even flames welcome at this point,
   Craig

PS  If you work from Oracle and are reading this, get back to work and
update your Kerberos base code!




 Original Message 
Subject: Re: KDC: upgrade to 3DES
Date: Thu, 7 Apr 2005 08:38:07 -0400 (EDT)
From: Shivakeshav Santi <[EMAIL PROTECTED]>
To: Jeffrey Altman <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>



Jeff,

Following are the answeres for the Qs:
1)did you rekey your principal (aka change your password?)
yes. Following is the output of getprinc :

Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 2, DES cbc mode with CRC-32, no salt
Key: vno 2, DES cbc mode with CRC-32, Version 4


2)is your client restricting the requested enctypes in the krb5.conf
file?
   it does allow des3-hmac-sha1 . Corresponding lines from krb5.conf :
   default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
   default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc


3)does the client you are using support 3DES?

   yes,I am using MIT kinit from krb51.3.4 .

Thanks for your help


> shivakeshav santi wrote:
>
>> HI,
>>
>>I am trying to upgrade  the encryption type on the KDC to support
>> 3DES. I have made the relevant changes in krb5.conf and
>> kdc.conf(supported_enctypes,
>> kdc_supported_enctypes,default_tgs_enctypes,default_tkt_enctypes
>> :des3-hmac-sha1 des-cbc-crc)
>>
>> But when I use kinit , I only get the tickets with single des.
>>  Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with
CRC-32
>>
>> Am I missing something.
>>
>> Thank you for your help.
>
> Just a few questions for you to answer:
>
> did you rekey your principal (aka change your password?)
>
> is your client restricting the requested enctypes in the krb5.conf
file?
>
> does the client you are using support 3DES?
>
> Jeffrey Altman
> ___
> krbdev mailing list [EMAIL PROTECTED]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>


-- 

Shivakeshav Santi

Programmer Analyst/Senior

Cornell Information Technologies
120 Maple Avenue
Cornell University
Tel :6072551916(O)

Ability may get you to the top, but only character will keep you there
.




___
krbdev mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/krbdev

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




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

RE: Unable to Authenticate some users...

[Tim Alsop]

Garry,

Can you provide me with some more details ? E.g. is your architecture
where you logon to Windows domain, then use a Kerberos enabled telnet
product to telnet onto the CISCO device (CISCO device running telnetd
with kerberos support) ? If not, please explain how you have this
implemented - I might be able to help.

Thanks, Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Garry J. Schindler
Sent: 01 April 2005 17:01
To: kerberos@mit.edu
Subject: Unable to Authenticate some users...

Hi,
 
We have a cisco 3000 concetrator setup, we wish our users to connect to
our VPN using the Kerberos/Active Directory from out 2003 Server.   Some
users can login, some cannot, and we along with Microsoft & Cisco in a
conference are unable to pinpoint the problem.
 
If we dont use Kerberos authentication works for everyone.   This is
connecting to a Microsoft 2003 Server.
 
Any ideas or examples of setup for us to try?
 
Any assistance appreciated.
 
Garry J. Schindler
Information Systems
MN State College SouthEast Tech




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

RE: "Permission denied in replay cache code" with SAP on Linux

[Tim Alsop]

Calin,

Yes, we know our competition as there are many SAP SNC certified products 
listed, some still available, some not - the others available, are not using 
Kerberos, but use Public Key, or a propriatory technology.

I suggest you need to read the license agreement which is shipped with MIT 
sources - it explains the "support" which is/isn't offered.

I don't think the MIT mailing list is appropriate to have this type of 
discussion - it is a technical discussion list, not for discussions about 
pros/cons of "open source" v "COTS" software. So, if you want to discuss this 
further I suggest we chat offlist.

Regards, Tim 

-Original Message-
From: Barbat, Calin [mailto:[EMAIL PROTECTED] 
Sent: 21 February 2005 11:05
To: Tim Alsop
Cc: kerberos@mit.edu
Subject: AW: "Permission denied in replay cache code" with SAP on Linux

Hello Mr. Alsop,

Thank you for the reminder, perhaps I'll come back to your offer. But don't 
rely on this affirmation, as there are other "commercially supported, and SAP 
AG certified" alternatives to your product. I assume you know your competition. 

Best regards and have a nice day,

Calin.

PS: I don't think MIT Kerberos V is unsupported, this is why these mailing 
lists are there and you can also get (and look at) the code. I'll let a copy of 
this message go to the Kerberos mailing list, others could have similar 
views/opinions and may be interested in your commercial, targeted offer.


-Ursprüngliche Nachricht-
Von: Tim Alsop [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 21. Februar 2005 11:38
An: Barbat, Calin
Cc: Tim Alsop
Betreff: RE: "Permission denied in replay cache code" with SAP on Linux


One of the disadvantages of using unsupported code, I guess :-) When you are 
ready to consider our commercially supported, and SAP AG certified product 
please let me know.

Take care,

Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barbat, Calin
Sent: 21 February 2005 10:33
To: kerberos@mit.edu
Subject: "Permission denied in replay cache code" with SAP on Linux

Hello friends,

after a while of running without problems I get the following trace from a SAP 
R/3 dialogue instance:

NFile "/usr/local/lib/snckrb5.so" dynamically loaded as SNC-Adapter.
NThe Adapter identifies as:
NExternal SNC-Adapter (Rev 1.0) to Kerberos 5/GSS-API v2
N  SncInit():   found snc/identity/as=p:[EMAIL PROTECTED]
N  *** ERROR => SncPAcquireCred()==SNCERR_GSSAPI  [sncxxall.c 1216]
NGSS-API(maj): Miscellaneous failure
NGSS-API(min): Permission denied in replay cache code
N  Could't acquire ACCEPTING credentials for
N
N  name="p:[EMAIL PROTECTED]"
N  SncInit(): Fatal -- Accepting Credentials not available!
N  <<- SncInit()==SNCERR_GSSAPI
N   sec_avail = "false"
M  ***LOG R19=> ThSncInit, SncInit ( SNC-04) [thxxsnc.c219]
M  *** ERROR => ThSncInit: SncInit (SNCERR_GSSAPI) [thxxsnc.c221]
M  in_ThErrHandle: 1
M  *** ERROR => SncInit (step 1, th_errno 44, action 3) [thxxhead.c 8015]

It seems to me that this message is Kerberos-related, has somebody any useful 
hint for me?
The main SAP instance is running on Solaris and some dialogue instances are on 
Linux.
 
Best regards,

Calin.


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







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

RE: Kerberos for windows support in Mozilla

[Tim Alsop]

Comments below prefixed with Tim>

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Wyllys Ingersoll
Sent: 02 February 2005 18:45
To: Sam Hartman
Cc: 'kerberos@mit.edu'; Douglas E. Engert
Subject: Re: Kerberos for windows support in Mozilla

Sam Hartman wrote:

>I'd like to echo Doug's comments.  I'm actually not at all sure you'd 
>want the default to be SSPI if you find a new enough KFW.  The intent 
>is that KFW will pick up SSPI credentials if necessary/desirable.  I 
>don't know that we are there yet but should be soon.
>  
>

If KfW were able to pick up SSPI creds then that would be very nice
indeed.
Then it wouldn't make a difference to the user what was happening under
the covers.

Tim> The CyberSafe library already 'picks up SSPI creds' in this way,
and has done so for over 3 years. It is indeed very nice :-)

As far as the default goes, I still think that SSPI has to be the
default since it is going to be available 100% of the time (for Win2K
and above, obviously).
KfW is not.  

Tim> I agree. The mozilla product should use SSPI as the default and if
configured to do so it should use the GSS-API library provided by the
Kerberos product installed. There should be no MIT specific or Heimdal
or CyberSafe specific code in this interface because Mozilla should be
able to use standard GSS-API calls to setup the security context with
the web server.

>We'd be happy to show you how to make this be a runtime option.  We'd
>  
>

I think making it a run-time option is really the key thing because I
doubt that anyone wants to maintain multiple windows binary
distributions and ask the users to choose "do you want the one that uses
Kerberos-for-Windows or SSPI?".
The average user (or even administrator) will have no idea what it means
to choose one or the other.

Tim> I agree. Runtime is the only solution that will be viable in my
opinion.

Assuming the KfW GSSAPI interface is just like the Unix one, then I
think very little new code would have to be added since the Unix/Linux
builds already work with GSSAPI.  The fixes would mostly be to the
configuration and build environment.

Tim> Wonderful. So, question is : who is going to be first to make these
changes to Windows version ??? :-)

-Wyllys


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




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

RE: Kerberos for windows support in Mozilla

[Tim Alsop]

Douglas,

I would be interested to discuss with somebody the possibility of
Mozilla being able to use the CyberSafe GSS-API library on Windows as
well as the MIT GSS, and perhaps (for completeness) the Hiemdal GSS
library as well... From our perspective I can see a need for this
functionality - as you mentioned, sometimes the workstation does not
have access to AD, or is part of a non-Microsoft Kerberos realm etc.

Regards, Tim. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Douglas E. Engert
Sent: 02 February 2005 17:46
To: Wyllys Ingersoll; 'kerberos@mit.edu'
Subject: Kerberos for windows support in Mozilla

Wyllys,
I saw your response to the bug report suggesting adding KfW support to
Mozilla for Windows.

https://bugzilla.mozilla.org/show_bug.cgi?id=280792

I think this would be a great idea, and people in the Kerberos community
would agree as well, and express their comments as well.

There are many windows machines that are not in a domain, or are on
travel and can not access the AD or are part of a Kerberos realm at all
yet the user would like to use Kerberos to access a web services.
These might even be now Windows servers that support SPNEGO line Apache.

Please reconsider your coments.




> 
> 
> Several applications like Vandyke Secure CRT allow the user to choose 
> on Windows when they use gss-api Kerberos authentication whether they 
> use the Windows SSPI or MIT Kerberos at runtime through configuration.

> I'm interested in Mozilla supporting this option as well. Would a 
> sufficient number of people find this useful to include it? We should 
> of course keep the default to SSPI for Windows platforms which support
it.
> 
> 
> --- Additional Comment #1 From Wyllys Ingersoll 2005-02-02 08:33 
> PST [reply] ---
> 
> In order to support  this, the host would have to already have the MIT

> Kerberos-For-Windows packages already installed.

Not really, the program checks for the existance of the dll.

> 
> I think there is a very tiny percentage of sites that would find this
useful.
> I don't really know if this could be a run-time option, it would most 
> likely have to be compiled at build time which makes it even less
attractive.
> 
> I really don't see what the functional benefit would be.  SSPI is 
> integrated in Windows and is wire-compatible with GSSAPI applications.

> Where is the benefit to the end user of having mozilla use GSSAPI on
Windows instead of SSPI?
> 
> 






-- 

  Douglas E. Engert  <[EMAIL PROTECTED]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

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: GSS API and impersonate client in the server

[Tim Alsop]

Doug,

You make some potenailly useful suggestions in your email. Mattias is
using is the CyberSafe product. So, we will compile a version on win2k3
and see if this helps, otherwise we will capture the packets using
ethereal and see if we can see any differences, or get additional
diagnostics.

Thanks, Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Douglas E. Engert
Sent: 02 November 2004 16:50
To: Mattias Karlsson
Cc: [EMAIL PROTECTED]
Subject: Re: GSS API and impersonate client in the server



Mattias Karlsson wrote:
> Hi and thanks for your answer.
> 
> I now have a GSS sample client that can authenticate to a SSPI sample 
> server. The sample server can then impersonate the client via the SSPI

> call ImpersonteSecurityContext.
> 
> However, this does not work if the SSPI sample server runs on a Win
> 2k3 SE machine. It works if the server runs on a XP (SP 1 or SP 2) or 
> a Win2K machine. This really puzzles me!
> 
> The error I get is a "Miscellaneous failure" with "Unknown error code"
> in the GSS sample client when feeding the gss_init_sec_context 
> function the token received from the server (gss_accept_sec_context 
> call).
> 
> Is it possible that some default configuration etc on Win 2K3 SE 
> triggers this? How is Win 2k3 SE different from XP/Win 2K (in a 
> "Kerberos view")?
> 

It could be that W2k3 is using some new features that are not supported
in your Kerberos, and it can't handle the returned message.


Could it also be you have to recompile the server for w2k3?

What version of Kerberos client are you using?

Do you have any trace like Ethereal?

The question is what was returned, an error, or some vaild message that
the client could not handle.


> Thanks
> Mattias
> 
> [EMAIL PROTECTED] ("Douglas E. Engert") wrote in message
news:<[EMAIL PROTECTED]>...
> 
>>If I am understand you reasoning you don't want to use SSPI because 
>>you have some unix servers and clients.
>>
>>But the SSPI and Kerberos GSSAPI use the same wire protocol, so you 
>>could be using InitializeSecurityContext on WIndows and 
>>gss_accept_sec_context on UNIXservers.
>>We do this all the time with a SecureCRT client on Windows using 
>>either Kerberos for Windows gssapi or MS SSPI Kerberos to OpenSSH sshd

>>server with MIT Kerberos gssapi.
>>
>>Going the other way with Unix client using gss_init_sec_context and a 
>>windows server using AcceptSecurityContext should also work and 
>>delegation should work. I have not tried this. There may be issues 
>>when you try and use the delegated credential to impersonate the user 
>>as it will need a PAC. Kerberos is strictly authentication. AD add to 
>>the Kerberos ticket authorization information. So it may mean you need

>>to use AD for the KDC.
>>
>>
>>Mattias Karlsson wrote:
>>
>>>Hi
>>>
>>>I'm about to kerberize our product and will use the gss api. When 
>>>analyzing the different components in our system I found that I need 
>>>to be able to impersonate the client in the server using the client 
>>>credentials. The reason for doing this is that the server needs to be

>>>able to access Windows resources (registry) with client permissions.
>>>
>>>How it works in the unkerberized client/server is that the client 
>>>sends it's Windows user and password to the server in the beginning 
>>>of the session. The server does a (WIN API) LogonUser and a 
>>>ImpersonateLoggedOnUser and can then act as the client in that
thread.
>>>
>>>I don't want to send user/password over the network but need to be 
>>>able to impersonate the client!
>>>
>>>The Windows SSPI API provides functions like 
>>>InitializeSecurityContext, AcceptSecurityContext and 
>>>ImpersonateSecurityContext but I don't want to use SSPI since I got 
>>>some UNIX servers and clients as well. Is it possible to use the 
>>>delegated_cred_handle or context_handle I get from the gss api call 
>>>gss_accept_sec_context and use it (maybe cast it) in the 
>>>ImpersonateSecurityContext function? Or is there some other way to do

>>>this? I assume I need to specify the GSS_C_DELEG_FLAG in the clients 
>>>gss_init_sec_context call, is there anything else that must be done?
>>>
>>>Thanks
>>>Mattias
>>>
>>>Kerberos mailing list   [EMAIL PROTECTED]
>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>>
>>>
>>
>> 
>>--
>>
>>  Douglas E. Engert  <[EMAIL PROTECTED]>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439
>>  (630) 252-5444
>>
>>Kerberos mailing list   [EMAIL PROTECTED]
>>https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> Kerberos mailing list   [EMAIL PROTECTED]
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <[EMAIL PROTECTED]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  

RE: GSSAPI - QOP and Kerberos encryption types

[Tim Alsop]

Markus,

Our application security library has an extension which may be what you
are looking for - see :

http://www.cybersafe.ltd.uk/online_docs/devpack1/appsecsdk/appsecsdk-32.
htm#csf_gss_get_context_options()

Thanks, Tim. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Sam Hartman
Sent: 25 October 2004 23:20
To: Markus Moeller
Cc: [EMAIL PROTECTED]
Subject: Re: GSSAPI - QOP and Kerberos encryption types

> "Markus" == Markus Moeller <[EMAIL PROTECTED]> writes:

Markus> Can I determine with gssapi calls the underlying Kerberos
Markus> encryption types or strength ? If so how would it work ?
Markus> Is there a table of QOP against Kerberos encryption types
Markus> ?

Not in the MIT implementation.

The latest Kerberos GSSAPI spec basically does away with qop.


Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Use of Encryption for KRB_AP_REQ

[Tim Alsop]

Hi,

The CyberSafe products support this cipher suite (e.g. 3DES-CBC-MD5),
however we use etype=5 for this suite which is different to other
implementations that use etype=5. This is clearly not a good approach
since every implementation that is using etype=5 should represent the
same (and compatible) cipher suite. We clearly have to be careful about
how our 3DES support is used by our customers. We will encourage the use
of AES instead when we have made this available in our products.

Is your requirement related to PacketCable or CableHome ? I ask this
because I am aware that these standards use 3DES-CBC-MD5 as the cipher
suite.

Thanks,
Tim Alsop
CyberSafe Limited
www.cybersafe.ltd.uk

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ahluwalia, Ish
Sent: 11 September 2004 00:43
To: [EMAIL PROTECTED]
Subject: Use of Encryption for KRB_AP_REQ

Hi All:

I'm new to kerberos world, so appologies in advance if it's too basic of
a question.  Does MIT kerberos support des3-cbc-md5 encryption type?  I
have a requirement which requires me to have the Authenticator field of
the AP_REQ to be encrypted using 3des-cbc-md5 encryption algorithm.
Looking at krb5.h file and the IETF specification, it doesn't look like
this algorithm is supported.  Any help will be greatly appreciated?  Is
there a way to get around this problem and still use MIT kerberos V5.

Thanks.

Ish... 


Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: "key type not supported" and XP SP2 changes ?

[Tim Alsop]

Comments inline prefixed with Tim> : 

-Original Message-
From: Jeffrey Altman [mailto:[EMAIL PROTECTED] 
Sent: 08 September 2004 09:19
To: Tim Alsop
Subject: Re: "key type not supported" and XP SP2 changes ?

Tim Alsop wrote:

> Jeffrey,
> 
> We have been using DES keys with MS AD KDC's for last 4 years and now 
> we have discovered we can use RC4-HMAC tgt with XP SP2. Before SP2 we 
> have been able to use RC4 tgt with Windows 2000 workstations only. We 
> are therefore trying to make it work with XP SP1.

This statement is one of the most confusing.  Under what conditions will
XP not obtain an RC4-HMAC session key?  I've been using XP for a long
time now and it always uses an RC4-HMAC key unless the user account has
been marked as DES only.

Tim> Yes, it will not get an RC4 session key when the account in AD is
marked as DES only. This is the only time it will not be RC4 as far as I
am aware and this is what I was referring to. I hope this clears up any
confusion.

Let us continue ...

> As I mentioned before we are not requesting the tgt so we cannot ask 
> for a DES-CBC-CRC or DES-CBC-MD5 tgt in the request. We are simply 
> reading the LSA cache and the Microsoft code is requesting the tgt 
> from AD. The way I understand it works is that our code reads the tgt 
> to check it is present and valid, then we read the service ticket to 
> see if this is present and valid. If the MS LSA sees a request to read

> a ticket that is not present it asks AD to issue the ticket rather 
> than answering "ticket not present". I also understand that our code 
> is validating the ticket by looking at the etype and this is causing 
> the problem when it sees the
> RC4 key.

This is where you are making your mistake.  The API for Requesting a
Ticket from the KDC is the KerbRetrieveTicketMessage.  If you ask it for
a service ticket of the form "krbtgt/[EMAIL PROTECTED]" you are asking for a
query to be sent to the KDC.  It is up to the LSA to determine if the
request is satisfied from the cache or not.  Requesting the TGT should
not in general be used to determine if the LSA is appropriately
authenticated using "Kerberos".  It does not matter if there is a TGT
there or not as Windows caches the username and password at logon.  If
there is no valid TGT, Windows will obtain one (if possible) when you
query for an arbitrary service ticket.

Tim> Ok, I am not a developer so I was not aware of this, but your
explanation makes sense. Thank you for educating me :-)

However, if you want to ensure that you obtain a TGT with a DES enctype
all you do is specify the EncryptionType of the
KERB_RETRIEVE_TKT_REQUEST to be DES_CBC_MD5 or DES_CBC_CRC and you will
get a TGT returned to you with a session key of the specified type.
Windows does not provide any API other than the
KerbRetrieveTicketMessage to obtain the body of a Kerberos ticket so I
know this is the API you must be using.

Tim> ok, as you know a gss-api application does not ask for a tgt so we
must be just asking for a service ticket (during the initiate context
request). When we ask for a service ticket the LSA will presumably
determine that a tgt already exists (with rc4 session key) and then (for
some reason) we get an error because our code does not recognise the rc4
etype.

If all you want to know is whether or not the cache contains a ticket
that is named "krbtgt/[EMAIL PROTECTED]" with a valid expiration time, then
you should not be using KerbRetrieveTicketMessage but instead should be
using either KerbQueryTicketCacheMessage (on Win2000) or
KerbQueryTicketCacheExMessage (on XP).  However, as I pointed out above
the failure to find a TGT in the cache is really meaningless given the
fact that the username and password for the Windows account used to
obtain the TGT are cached in the LSA.

Tim> we are not planning to change the way our code works - we just want
to understand why we get this problem with SP1 and see if there is a way
to make SP1 work same way as SP2. Clearly there are many things we can
do to our code to circumvent the Sp2 upgrade and this is being
considered as one of the options, but the preferred option is for MS to
issue a hotfix in order to allow the SP2 functionality to be available
in pre-SP2 XP workstations.

> In response to Sam's suggestion about mapping unsupported keytypes - 
> yes, this is an option for us, but we are trying to investigate all 
> options available and make a decision about the best way forward in 
> short term. It appears the main options are (in no particular order) 
> (i) convince customer to upgrade to SP2, (ii) add rc4 support to our 
> code quicker than previously planned, (iii) modify our code so it 
> ignores the error or maps rc4 onto null etype, (iv) use des keys for
user accounts.

There is no need for any of this.

Tim> So, if there is no need fo

RE: "key type not supported" and XP SP2 changes ?

[Tim Alsop]

Jeffrey,

We have been using DES keys with MS AD KDC's for last 4 years and now we
have discovered we can use RC4-HMAC tgt with XP SP2. Before SP2 we have
been able to use RC4 tgt with Windows 2000 workstations only. We are
therefore trying to make it work with XP SP1. 

As I mentioned before we are not requesting the tgt so we cannot ask for
a DES-CBC-CRC or DES-CBC-MD5 tgt in the request. We are simply reading
the LSA cache and the Microsoft code is requesting the tgt from AD. The
way I understand it works is that our code reads the tgt to check it is
present and valid, then we read the service ticket to see if this is
present and valid. If the MS LSA sees a request to read a ticket that is
not present it asks AD to issue the ticket rather than answering "ticket
not present". I also understand that our code is validating the ticket
by looking at the etype and this is causing the problem when it sees the
RC4 key.

In response to Sam's suggestion about mapping unsupported keytypes -
yes, this is an option for us, but we are trying to investigate all
options available and make a decision about the best way forward in
short term. It appears the main options are (in no particular order) (i)
convince customer to upgrade to SP2, (ii) add rc4 support to our code
quicker than previously planned, (iii) modify our code so it ignores the
error or maps rc4 onto null etype, (iv) use des keys for user accounts.

We are only looking for this solution for 1 client who cannot upgrade to
SP2 for other reasons. Our product is the first product that will be
using kerberos other than MS operating system use of the protocol. I
don't understand why upgrading kerberos.dll is any different to being
able to apply the part of SP2 that is needed - are you suggesting that
SP2 will break other third party products ?

Yes, we plan to open a PSS request with MS if we decide this is the best
way forward in short term.

Thanks again,

Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jeffrey Altman
Sent: 07 September 2004 23:53
To: [EMAIL PROTECTED]
Subject: Re: "key type not supported" and XP SP2 changes ?

Tim:

You have not provided enough information to show how your code is ending
up with the RC4-HMAC session key.  The XP SP2 changes have only been
around for the last four weeks in production code.  What have you been
doing for the last four years to make your code work with Windows 2000
and XP?

If the only enctypes which are common between your libraries and the
Windows Kerberos are DES-CBC-CRC and DES-CBC-MD5, then you must request
tickets by specifying one of those enctypes at the time you request
them.  Otherwise, you are likely to end up with RC4-HMAC as the session
key type when talking to Active Directory unless the account associated
with the SPN has been configured to be DES only.

Asking your clients to install a new version of Kerberos.dll on their
systems is going to break other third party products which rely on the
Kerberos SSP functionality as determined by the operating system version
number.  For that reason I doubt that Microsoft would issue such a
change.  Of course, you could always file a PSS request if you have a
support contract.

Jeffrey Altman


Tim Alsop wrote:

> Jeffrey,
> 
> Sorry to be confusing. Our code is not requesting a tgt, but I know 
> for a fact that setting AllowTGTSessionKey to 0 on XP SP2 (the default
> setting) causes our code to work as required, but setting it to 1 
> causes it to complain with "key type not supported". My explanation I 
> have given so far has been based on my assumptions from this test - 
> maybe wrongly, but I am trying to draw a conclusion and it seems 
> likely to me that if the key is not exported we don't give an error 
> because we don't see the RC4 key. Maybe this conclusion is incorrect, 
> but it does not change the fact that if we had the support for 
> AllowTGTSessionKey on
> pre-SP2 XP systems we could provide a quick solution to the problem 
> discovered by our customer.
> 
> I realy do apprecaite your help so far with this issue. I hope my 
> explanation above helps ?
> 
> Take care,
> 
> Tim.
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Jeffrey Altman
> Sent: 07 September 2004 20:30
> To: [EMAIL PROTECTED]
> Subject: Re: "key type not supported" and XP SP2 changes ?
> 
> Tim Alsop wrote:
> 
> 
>>Tim> we don't want to extract a tgt from lsa cache. This is not
>>necessary because our Kerberos library interfaces with LSA and 
>>requests a service ticket. The service ticket request is handled by MS
> 
> 
>>code and the MS Kerberos library (e.g. LSA) sends the request to MS AD
> 
> 
>>KDC. Our Kerberos library does not need any access to the Key, but 
&

RE: "key type not supported" and XP SP2 changes ?

[Tim Alsop]

Jeffrey,

Sorry to be confusing. Our code is not requesting a tgt, but I know for
a fact that setting AllowTGTSessionKey to 0 on XP SP2 (the default
setting) causes our code to work as required, but setting it to 1 causes
it to complain with "key type not supported". My explanation I have
given so far has been based on my assumptions from this test - maybe
wrongly, but I am trying to draw a conclusion and it seems likely to me
that if the key is not exported we don't give an error because we don't
see the RC4 key. Maybe this conclusion is incorrect, but it does not
change the fact that if we had the support for AllowTGTSessionKey on
pre-SP2 XP systems we could provide a quick solution to the problem
discovered by our customer.

I realy do apprecaite your help so far with this issue. I hope my
explanation above helps ?

Take care,

Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jeffrey Altman
Sent: 07 September 2004 20:30
To: [EMAIL PROTECTED]
Subject: Re: "key type not supported" and XP SP2 changes ?

Tim Alsop wrote:

> Tim> we don't want to extract a tgt from lsa cache. This is not
> necessary because our Kerberos library interfaces with LSA and 
> requests a service ticket. The service ticket request is handled by MS

> code and the MS Kerberos library (e.g. LSA) sends the request to MS AD

> KDC. Our Kerberos library does not need any access to the Key, but 
> since it sees the key and we have validation code to check for etypes 
> that are supported (for other reasons) our code gives "key type not
supported"
> error.

If you are not requesting the TGT then the AllowTGTSessionKey flag does
not come into play at all.


> Tim> we are not looking to use DES enc type. The expectation is that 
> Tim> RC4
> keys can be used for TGT, but when a tgt is stored in the LSA cache we

> don't see the RC4 key (e.g. AllowTGTSessionKey = 0). If we see the key

> our code considers this to be an error - we are trying to avoid this 
> but cannot on pre-SP2 versions of XP.

What AllowTGTSessionKey does is allow the session key to be exported.
If it cannot be exported the encryption type is set to 0 (ENCTYPE_NULL).

I really suggest that you fix your code.  Setting the AllowTGTSessionKey
value to 0 breaks KFW and it breaks Java Kerberos.

> Tim> Our code has a similar cache type to hide any specifics from the
> application. Our implementation will eventually support the RC4 etype 
> so this will work better then, but we have an existing customer who 
> cannot deploy SP2 for a while and are trying to see if there is a 
> short term solution for them.

Your statements are so confusing.  You have said repeatedly that the
reason you need to AllowTGTSessionKey flag is because you need to hide
the RC4-HMAC enctype from your application.  But now you say the
customer is having problems installing XP SP2 which is where the default
behavior is "AllowTGTSessionKey = 0.  Which is it?


> Tim> If MS were able to implement the AllowTgtSessionKey that is in
SP2
> so that it can be added by hotfix to SP1 XP workstations this will
solve
> our problem.

My confusion continues.  How does this solve your problem?
Why is your application caring about the session key enctype of the TGT
when it is not attempting to use the TGT to obtain a service ticket?

Jeffrey Altman



-- 
-
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: "key type not supported" and XP SP2 changes ?

[Tim Alsop]

Jeffrey,

My comments below (inline).

Cheers, Tim 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jeffrey Altman
Sent: 07 September 2004 17:59
To: [EMAIL PROTECTED]
Subject: Re: "key type not supported" and XP SP2 changes ?

Tim:

The AllowTGTSessionKey registry value implemented in XP SP2 allows
the exportation of all TGT session keys.   Without this registry value
being set it will be impossible to extract a TGT from the LSA cache
which contains a valid session key of any type.  The AllowTGTSessionKey
flag does not have any impact on the session key type obtained from the
Active Directory KDC.

Tim> we don't want to extract a tgt from lsa cache. This is not
necessary because our Kerberos library interfaces with LSA and requests
a service ticket. The service ticket request is handled by MS code and
the MS Kerberos library (e.g. LSA) sends the request to MS AD KDC. Our
Kerberos library does not need any access to the Key, but since it sees
the key and we have validation code to check for etypes that are
supported (for other reasons) our code gives "key type not supported"
error.

If you need a DES enctype from the LSA you should simply ask the LSA to
give you one using the EncryptionType field of the
KERB_RETRIEVE_TICKET_REQUEST.  The behaviors of the
KerbRetrieveTicketMessage are slightly different in each operating
system and service pack.  (The differences are not well documented.)

Tim> we are not looking to use DES enc type. The expectation is that RC4
keys can be used for TGT, but when a tgt is stored in the LSA cache we
don't see the RC4 key (e.g. AllowTGTSessionKey = 0). If we see the key
our code considers this to be an error - we are trying to avoid this but
cannot on pre-SP2 versions of XP.

The MIT Kerberos for Windows distribution hides all of the LSA cache
variations from the application via the MSLSA krb5_ccache type.  MIT's
implementation of course supports the RC4-HMAC enctype so it does not
suffer from the problems that implementations such as yours and Sun's
Java Kerberos run into.

Tim> Our code has a similar cache type to hide any specifics from the
application. Our implementation will eventually support the RC4 etype so
this will work better then, but we have an existing customer who cannot
deploy SP2 for a while and are trying to see if there is a short term
solution for them.

Tim> If MS were able to implement the AllowTgtSessionKey that is in SP2
so that it can be added by hotfix to SP1 XP workstations this will solve
our problem.

Jeffrey Altman




Tim Alsop wrote:

> Hi,
> 
> As you can see below I am trying to find out if we can implement the 
> AllowTGTSessionKey registry setting in pre-SP2 versions of XP.
> 
> There is no MSGINA replacement involved since the standard XP SP1 gina

> is being used to get the tgt. The tgt is obtained successfully, but 
> since the tgt is used to get a service ticket (in tgs-req) our 
> kerberos library on XP needs to read the LSA cred cache and it doesn't

> like the
> RC4 key it finds. We therefore need to find an easy way to stop this 
> key being exported on pre-SP2 versions of XP.
> 
> Thanks, Tim. 

--
-
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: "key type not supported" and XP SP2 changes ?

[Tim Alsop]

Hi,

As you can see below I am trying to find out if we can implement the
AllowTGTSessionKey registry setting in pre-SP2 versions of XP.

There is no MSGINA replacement involved since the standard XP SP1 gina
is being used to get the tgt. The tgt is obtained successfully, but
since the tgt is used to get a service ticket (in tgs-req) our kerberos
library on XP needs to read the LSA cred cache and it doesn't like the
RC4 key it finds. We therefore need to find an easy way to stop this key
being exported on pre-SP2 versions of XP.

Thanks, Tim. 

-Original Message-
From: Jeffrey Altman [mailto:[EMAIL PROTECTED] 
Sent: 07 September 2004 16:12
To: Tim Alsop
Cc: [EMAIL PROTECTED]
Subject: Re: "key type not supported" and XP SP2 changes ?

I am confused about two things:

(1) why is this discussion taking place on an IETF mailing list?
 an appropriate place for this discussion would be [EMAIL PROTECTED]
 or one of the Microsoft specific security newsgroups

(2) AllowTGTSessionKey applies to Windows 2003 and XP SP2 (and may
 apply to a future 2000 service pack).  In all other versions of
 Windows, the TGT session key will always be exported upon request.
 Therefore, if you have an RC4 session key in the TGT, then it will
 be exported by default on pre-XP SP2 systems but not in XP SP2.
 Your problem description therefore seems reversed.

I suggest you post this query to [EMAIL PROTECTED] and include a
description of what your MSGINA does to obtain a TGT.

Jeffrey Altman



Tim Alsop wrote:

> Hi,
>  
> After further investigation the reason for this problem has been 
> identified. It is occuring because of AllowTgtSessionKey not being a 
> valid registry setting in XP SP1. Basically the Kerberos library does 
> not recognise RC4 session keys so it gives an error, but if 
> AllowTGTSessionKey is 0 (default on SP2) it does not see a session key

> that it doesn't recognise.
>  
> The customer that this problem relates to is not planning to install 
> SP2 for about 9 months so we need to see if there is a way to 
> implement the AllowTGTSessionKey as a hotfix to SP1 instead of 
> installing SP2. Does anybody know if there is such a fix available ?
>  
> Thanks, Tim.
> 
> --
> --
> *From:* [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Tim 
> Alsop
> *Sent:* 07 September 2004 12:28
> *To:* [EMAIL PROTECTED]
> *Subject:* "key type not supported" and XP SP2 changes ?
> 
> Hi,
> We are using a gss-api library that only supports DES and 3DES - when 
> we initiate a security context using an RC4 tgt issued during MS GINA 
> logon we can obtain a service ticket (using DES-MD5) from AD KDC, but 
> only if Windows XP SP2 is installed. If we remove SP2 and go back to 
> SP1 we get "key type not supported". We are therefore trying to find 
> out what changes were made in SP2 that might cause this to occur ? 
> Does anybody have any ideas ?
> Thanks, Tim




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: BC-SNC, MIT Kerberos V, SSO, GSS-API v2

[Tim Alsop]

Calin,

I appreciate your email. Thanks, and good luck.

Regards,
Tim.

-Original Message-
From: Barbat, Calin [mailto:[EMAIL PROTECTED] 
Sent: 17 August 2004 08:13
To: Tim Alsop
Cc: [EMAIL PROTECTED]
Subject: AW: BC-SNC, MIT Kerberos V, SSO, GSS-API v2

Tim,

I'm not interested in a commercial product, I already know there are
several certified products around there; but e.g. the Duke University
uses MIT Kerberos to do the job - seen it yesterday on URL: 

http://www.oit.duke.edu/techsupport/sap/sapgui/linux/

So I'd like to figure out how to properly configure Kerberos, as the
libgssapi_krb5.so seems to work out of the box for them.

Anyway, thank you for your marketing effort,

Calin Barbat.

-Ursprüngliche Nachricht-----
Von: Tim Alsop [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 16. August 2004 18:59
An: Barbat, Calin
Cc: [EMAIL PROTECTED]
Betreff: RE: BC-SNC, MIT Kerberos V, SSO, GSS-API v2


Calin,

We can solve this problem using our GSS library which works in a
consistent manner with SAP SNC on all platforms (including Linux). Our
product is "Certified for SAP NetWeaver"

So, if you are interested in a BC-SNC supported gss library for Linux
please refer to www.cybersafe.ltd.uk/links/sap.htm

Let me know if you have any further questions by emailing me off-list.

Thanks, Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Barbat, Calin
Sent: 13 August 2004 10:37
To: [EMAIL PROTECTED]
Subject: BC-SNC, MIT Kerberos V, SSO, GSS-API v2

Hello everybody,

I need help with Single Sign-On for SAPguis running on Windows clients
to an SAP Application Server 4.6C running on a Linux SLES server with
authentification against an Active Directory provided by a Windows 2000
Server.

In the following I'll describe how far I got, so the specialists can
help with the remaining things to do.

I'm trying now to get the actual Kerberos implementation (release 1.3.1)
from MIT to work with our SAP Application Server 4.6C. 
Could it be that I need an older release? If so, which one and where can
I get it?

As I understand, the libgssapi_krb5.so library has to be tested for
interoperability with a tool named gsstest, which is provided for free
by SAP.

I compiled, installed and configured Kerberos on the Linux AS and got a
logon ticket from the Win2k KDC by logging in on the Linux prompt using:

  kinit C.Barbat

This ticket is shown by: 

  klist

Then I issued:

  gsstest-1.27/gsstest -l /usr/local/lib/libgssapi_krb5.so -d 4 -p
kerberos_test.log

This should test the library libgssapi_krb5.so with the most verbose
output to kerberos_test.log.

This file reads as follows:


 

**
  ***
***
  ***  "gsstest" -- GSS-API v2  Shared Library API Test Program
***
  ***
***
  ***  Version 1.27   11-Apr-2003
***
  ***
***
  ***  This implementation is Copyright (c), 1998  SAP AG Walldorf
***
  ***
***
 

**
  ***  This tool may be freely used to test functionality and
***
  ***  robustness of GSS-API v2 mechanism implemenations
***
 

**
  *** THIS SOFTWARE IS PROVIDED BY SAP AG ``AS IS'' AND ANY EXPRESSED
***
  *** OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
***
  *** IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
***
  *** PURPOSE ARE DISCLAIMED. SAP AG SHALL BE LIABLE FOR ANY DAMAGES
***
  *** ARISING OUT OF THE USE OF THIS SOFTWARE ONLY IF CAUSED BY SAP AG'S
***
  *** INTENT OR GROSS NEGLIGENCE. IN CASE SAP AG IS LIABLE UNDER THIS
***
  *** AGREEMENT FOR DAMAGES CAUSED BY SAP AG'S GROSS NEGLIGENCE SAP AG
***
  *** FURTHER SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
***
  *** EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO,***
  *** PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
***
  *** OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
***
  *** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
***
  *** OR TORT, AND SHALL NOT BE LIABLE IN EXCESS OF THE AMOUNT OF
***
  *** DAMAGES TYPICALLY FORESEEABLE FOR SAP AG, WHICH SHALL IN NO EVENT
***
  *** EXCEED US$ 500.000.-
***
 

**

Timer resolution of gettimeofday() is (at least)  0.001 millisec
1 second passed in   1000.000 millisec.

=
  Current Date&Time :  Fri, 13-Aug-2004   08:55:05   GMT +00:00
  Operating System  :  Linux
  -Release  :  2.4.21-190-smp
  Hardware/Machine  :  i686
  scalar C-types:  void* ptrdiff_t size_t time_t long int wchar_t
char
(sizes in bits) :32 32s  32u32s   32s 32s   32s
8u
  Endianess, Charset:  1234 (LITTLE_ENDIAN),  ASCI

RE: Problem changing expired Windows 2000 passwords

[Tim Alsop]

The "Windows cache" is the cache which you can view when using
kerbtray.exe. I didn't try, but I guess you would also see this when
using klist.exe or any other tool that looks in LSA cache.

Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jeffrey Altman
Sent: 17 August 2004 16:46
To: [EMAIL PROTECTED]
Subject: Re: Problem changing expired Windows 2000 passwords

What is "Windows cache"?  Do you mean "KLIST"? "KERBTRAY"?

Or do you mean the ClientName and ClientRealm fields of
KERB_TICKET structures?



Tim Alsop wrote:

> Hi,
> 
> I am not sure if this is useful or not, but we recently noticed
> something odd when logging in with [EMAIL PROTECTED] If you login with an
> account name of this format and the account is set to use DES keys the
> client principal name shown in Windows cache is [EMAIL PROTECTED]@REALM
> instead of [EMAIL PROTECTED] ...
> 
> Regards, Tim.

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Problem changing expired Windows 2000 passwords

[Tim Alsop]

Hi,

I am not sure if this is useful or not, but we recently noticed
something odd when logging in with [EMAIL PROTECTED] If you login with an
account name of this format and the account is set to use DES keys the
client principal name shown in Windows cache is [EMAIL PROTECTED]@REALM
instead of [EMAIL PROTECTED] ...

Regards, Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jeffrey Altman
Sent: 17 August 2004 16:06
To: [EMAIL PROTECTED]
Subject: Re: Problem changing expired Windows 2000 passwords

I believe this is a documented bug which Microsoft chooses not to
fix.  The user is required to login using

[EMAIL PROTECTED]

instead of just the username.

Jeffrey Altman


[EMAIL PROTECTED] wrote:

> Hi!
> 
> We have a Windows 2000 domain with workstations performing
authentication
> at a MIT Kerberos KDC.  It works fine but, if the user's password has
> expired, the Windows workstations displays it's normal "password
expired"
> alert, but when the user tries to change this password, Windows shows
the
> "domain not available" message.
> 
> Running tcpdump at the kdc, I show no kerberos related traffic when
this
> password-change is tried.
> 
> There is a article at Microsoft about a similar problem, but it says
the
> issue is solved with service pack 1.  We have service pack 4 at our
> windows workstations.
> 
> Some idea???
> 
> Tnks!
> 
> []s!
> Rodolfo
> 
> 
> 
> Kerberos mailing list   [EMAIL PROTECTED]
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 

-- 
-
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: BC-SNC, MIT Kerberos V, SSO, GSS-API v2

[Tim Alsop]

Calin,

We can solve this problem using our GSS library which works in a
consistent manner with SAP SNC on all platforms (including Linux). Our
product is "Certified for SAP NetWeaver"

So, if you are interested in a BC-SNC supported gss library for Linux
please refer to www.cybersafe.ltd.uk/links/sap.htm

Let me know if you have any further questions by emailing me off-list.

Thanks, Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Barbat, Calin
Sent: 13 August 2004 10:37
To: [EMAIL PROTECTED]
Subject: BC-SNC, MIT Kerberos V, SSO, GSS-API v2

Hello everybody,

I need help with Single Sign-On for SAPguis running on Windows clients
to an SAP Application Server 4.6C running on a Linux SLES server with
authentification against an Active Directory provided by a Windows 2000
Server.

In the following I'll describe how far I got, so the specialists can
help with the remaining things to do.

I'm trying now to get the actual Kerberos implementation (release 1.3.1)
from MIT to work with our SAP Application Server 4.6C. 
Could it be that I need an older release? If so, which one and where can
I get it?

As I understand, the libgssapi_krb5.so library has to be tested for
interoperability with a tool named gsstest, which is provided for free
by SAP.

I compiled, installed and configured Kerberos on the Linux AS and got a
logon ticket from the Win2k KDC by logging in on the Linux prompt using:

  kinit C.Barbat

This ticket is shown by: 

  klist

Then I issued:

  gsstest-1.27/gsstest -l /usr/local/lib/libgssapi_krb5.so -d 4 -p
kerberos_test.log

This should test the library libgssapi_krb5.so with the most verbose
output to kerberos_test.log.

This file reads as follows:


 

**
  ***
***
  ***  "gsstest" -- GSS-API v2  Shared Library API Test Program
***
  ***
***
  ***  Version 1.27   11-Apr-2003
***
  ***
***
  ***  This implementation is Copyright (c), 1998  SAP AG Walldorf
***
  ***
***
 

**
  ***  This tool may be freely used to test functionality and
***
  ***  robustness of GSS-API v2 mechanism implemenations
***
 

**
  *** THIS SOFTWARE IS PROVIDED BY SAP AG ``AS IS'' AND ANY EXPRESSED
***
  *** OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
***
  *** IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
***
  *** PURPOSE ARE DISCLAIMED. SAP AG SHALL BE LIABLE FOR ANY DAMAGES
***
  *** ARISING OUT OF THE USE OF THIS SOFTWARE ONLY IF CAUSED BY SAP AG'S
***
  *** INTENT OR GROSS NEGLIGENCE. IN CASE SAP AG IS LIABLE UNDER THIS
***
  *** AGREEMENT FOR DAMAGES CAUSED BY SAP AG'S GROSS NEGLIGENCE SAP AG
***
  *** FURTHER SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
***
  *** EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO,***
  *** PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
***
  *** OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
***
  *** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
***
  *** OR TORT, AND SHALL NOT BE LIABLE IN EXCESS OF THE AMOUNT OF
***
  *** DAMAGES TYPICALLY FORESEEABLE FOR SAP AG, WHICH SHALL IN NO EVENT
***
  *** EXCEED US$ 500.000.-
***
 

**

Timer resolution of gettimeofday() is (at least)  0.001 millisec
1 second passed in   1000.000 millisec.

=
  Current Date&Time :  Fri, 13-Aug-2004   08:55:05   GMT +00:00
  Operating System  :  Linux
  -Release  :  2.4.21-190-smp
  Hardware/Machine  :  i686
  scalar C-types:  void* ptrdiff_t size_t time_t long int wchar_t
char
(sizes in bits) :32 32s  32u32s   32s 32s   32s
8u
  Endianess, Charset:  1234 (LITTLE_ENDIAN),  ASCII charset
  Perf-Index (p-90) :  dbg= 7.40   (opt= 3.80)
  Timer Resolution  :  0.001 millisec using "gettimeofday()"
  Hostname  :  app-r3-portal
  Current user  :  cb
=

Loading GSS-API shared library #1 "/usr/local/lib/libgssapi_krb5.so" ...

  Resolving SAP SNC-Adapter functions ...
GSS-API v2  "sapsnc_init_adapter"  (  opt.   )
(missing)
GSS-API v2  "sapsnc_export_cname_blob" (  opt.   )
(missing)
GSS-API v2  "sapsnc_import_cname_blob" (  opt.   )
(missing)
  Resolving Misc Support functions ...
GSS-API v1  "gss_indicate_mechs"   (REQUIRED )
ok.
GSS-API v1  "gss_display_status"   (REQUIRED )
ok.
GSS-API v1  "gss_release_buffer"   (REQUIRED )
ok.
GSS-API v1  "gss_release_oid_set"  (REQUIRED )
ok.
GSS-API v2  "gss_inquire_names_for_mech"   (requested)
ok.
  

IIS and Kerberos authentication

[Tim Alsop]

Hi,

 

We noticed that if we use IIS 5 (or 6) with Kerberos authentication by
enabling "Integrated Windows Authentication" in IE and IIS settings -
when a user is authenticated the REMOTE_USER HTTP header variable
contains "domain\user" (NTLM format) instead of "[EMAIL PROTECTED]" (Kerberos
format). We cannot reliably change domain\user into [EMAIL PROTECTED] in our
code because there is not necessarily a 1:1 map between an NTLM format
domain\user and the associated Kerberos principal name of the same user
(due to case issues, aliases, how user account was configured in domain
controller etc.).

 

Does anybody know an easy way to solve this ?

 

We are going to develop an ISAPI filter to meet our needs if nobody else
has any better suggestions.

 

Thanks, Tim.

 


Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Two-factor Authentication Options?

[Tim Alsop]

Henry,

The CyberSafe TrustBroker products currently support RSA SecurID, VASCO
Digipass and SecureComputing SafeWord tokens. They also support smart
cards via PKINIT.

Thanks, Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Henry B. Hotz
Sent: 15 July 2004 19:10
To: [EMAIL PROTECTED]
Subject: Two-factor Authentication Options?

In the long run the Kerberos password is a problem because the human  
brain does not obey Moore's law.  As I see it the solution is to use  
some form of two-factor authentication for the initial ticket exchange.

So what options are there in that space?

AFAIK none --- with the standard open source servers.  There are  
patches available for MIT to support CRYPTOcard and SecureID.  There  
are patches available for Heimdal to support X509 certificates  
(PKINIT).

Anything else out there?

While I'm on the subject, let me throw out an idea:  smart card  
authentication that requires an existing tgt to authenticate.  The user

first gets an ordinary tgt for [EMAIL PROTECTED]  Then (s)he uses that tgt  
in conjunction with with the smart card (IF details unspecificed) to  
acquire a tgt for either smith/[EMAIL PROTECTED], or [EMAIL PROTECTED]   
This isn't the forum to discuss a new proposal, but maybe someone knows

of something?



The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]


Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: kerberos - proxy

[Tim Alsop]

Enrico,

I suggest we continue this discussion offline rather than via
[EMAIL PROTECTED]

Thanks,
Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Carretti Enrico
Sent: 09 July 2004 11:16
To: [EMAIL PROTECTED]
Subject: kerberos - proxy

>We have a product which is designed to use Kerberos with Apache (1.3 or

>2.0) when it is configured as a proxy. The regular SPNEGO Kerberos 
>solution available for Apache, IE, Mozilla etc. will not work with
proxy 
>servers. 
> 
>Please let me know if you are interested and I can send you more 
>details. 
> 
>Regards, Tim. 
Hi Tim, 
I,m very interested! In this moment I'm using my Apache 2.0 to run as a 
"normal" web server; to get the clients authenticate against kerberos to

accesso certaing pages I've used a third part module called
mod_auth_kerb (see 
sourceforge.net for more details) which allows Apache and Kerberos to 
dialogue. Now I want to make something different and I desire something
that 
allows Apache to request kerberos auth when it runs as a forward proxy.
In 
conclusion I need to request auth every time that a host of my lan
requires to 
Apache proxy an HTTP session. Thank very much in advance 
Enrico 

-
This mail sent through IMP: http://horde.org/imp/


Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: kerberos - proxy

[Tim Alsop]

Enrico,

We have a product which is designed to use Kerberos with Apache (1.3 or
2.0) when it is configured as a proxy. The regular SPNEGO Kerberos
solution available for Apache, IE, Mozilla etc. will not work with proxy
servers.

Please let me know if you are interested and I can send you more
details.

Regards, Tim.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Carretti Enrico
Sent: 09 July 2004 10:50
To: [EMAIL PROTECTED]
Subject: kerberos - proxy

Hi all, 
I'm interested in using kerberos to authenticate clients requiring
services to 
my proxy (i've configured Apache to run as aforward proxy); can anyone 
suggests some ways to do this type of auth?? Thanks all in advance 
Enrico 
 

-
This mail sent through IMP: http://horde.org/imp/


Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: RBAC and Kerberos?

[Tim Alsop]

Christopher,

I am currently working with OASIS SSTC to progress Kerberos/SAML
integration standards.

If you can explain to me in a bit more detail off-list how you think
SAML and Kerberos should work together I will be able to let you know if
our current work in OASIS covers your needs.

Thanks,

Tim Alsop

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Nebergall, Christopher
Sent: 03 June 2004 00:06
To: 'Digant Kasundra'; bart.w.jenkins; [EMAIL PROTECTED]
Subject: RE: RBAC and Kerberos?

>>>Kerberos fits in best as an AuthN system.  It can very easily tie
into
LDAP which can support your AuthZ needs.

This is true within a single enterprise.   LDAP support for
authorization
becomes more difficult once you are talking about federation between
different organizations.  It requires you to expose your directory
server
outside your internal firewall and for partner site(s) to have intimate
knowledge of your directory schema.  In the web authentication world
SAML
was developed to ease some of these some of these burdens by defining a
language to share attributes more easily. Does anyone know if there is
research to use SAML and Kerberos together (SAML as the PAC data)?

Christopher Nebergall


-Original Message-
From: Digant Kasundra [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 02, 2004 4:25 PM
To: bart.w.jenkins; [EMAIL PROTECTED]
Subject: RE: RBAC and Kerberos?

In a core enterprise IT, you have 2 "systems": AuthN (authentication)
and
AuthZ (authorization).  Kerberos fits in best as an AuthN system.  It
can
very easily tie into LDAP which can support your AuthZ needs.

-- DK


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of bart.w.jenkins
> Sent: Wednesday, June 02, 2004 1:12 PM
> To: [EMAIL PROTECTED]
> Subject: RBAC and Kerberos?
> 
> 
> All,
> I would love to use MIT's Kerberos, but it looks as though it 
> can NOT do Role Based Access Control (RBAC) out of the box.  
> It seems that MIT's Kerberos stores only principals and knows 
> nothing about any roles those principals might or might not 
> have.  For any particular user, I would love to be able to 
> attach a list of roles that person plays.  For example, for 
> user Joe, I need to be able to say that principal Joe has 
> roles: Admin, Superuser or Manager or Supervisor, or 
> Team1Leader etc.  Then, when Joe authenticates to the KDC, if 
> both the principal (what Java JAAS calls the
> subject) could also return a list of roles (JAAS principals), 
> I could then do RBAC.  Microsoft had to add some separate 
> user-to-role database that is consulted when user's 
> authenticate in their Active Directory realm.  I would like 
> to not have to do this.  Does anyone know of a Kerberos 
> implementation that does RBAC and, BTW, works with Sun's JAAS 
> (Java security)?
> 
> I could just have user Kerberos principals and Role 
> principals, but then when someone logged in with a Role user 
> id, I would not know who the underlying user was.  It seems 
> that adding some Role attributes to the kerb principal would 
> help alot here.
> 
> Thanks
> 
> Bart
> 
> 
> 
> Kerberos mailing list   [EMAIL PROTECTED]
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos


Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: kinit programming

[Tim Alsop]

Hi,

I suspect they used static linking so that the required Kerberos protocol functions 
are included in the binary instead of using dynamic linking, so that it calls a shared 
library such as libkrb during execution.

BTW. Our Application Security products provide an implementation og GSSAPI v2 and also 
include additional functions for application security, these include functions for 
acquiring initial credentials. See 
http://www.cybersafe.ltd.uk/menu_prodsolserv/products/products_appsec_sdk.htm for more 
details.

Thanks, Tim. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: 16 April 2004 21:01
To: [EMAIL PROTECTED]
Subject: Re: kinit programming

[EMAIL PROTECTED] (melissa_benkyo) wrote in message news:<[EMAIL PROTECTED]>...
> hello all,
> 
> I finally got the gss-server and gss-client and kerberos setups under
> control. :D Now I post another problem for you guys. right now I need
> to do a kinit before I proceed to use the gss-sample code. Is it
> possible to code the kinit program? can this be done using gss-api
> calls or kerberos calls?
> 
> any insights are much appreciated. thanks!
> have a nice weekend guys! 
> 
> melissa

anybody has any idea how the Solaris implemented SEAM's kinit? its
weird because solaris doesn't have the libkrb? or at least the kinit
doesn't seem to be using it. so it means it is using the libgss ones
but it is stated that gss api doesn't handle initial credentials.

any thoughts people.

thanks

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: client-side support for SASL/GSSAPI on windows?

[Tim Alsop]

The indication from this page is that the SASL-GSSAPI builds against
the CyberSafe sources.  You should be able to modify that to build 
against the MIT Kerberos for Windows 2.6.x SDK quite easily.

Response from CyberSafe : 

Alternatively, you could use the CyberSafe runtime library which works with the 
Microsoft credential cache without changes. We also include an MMC plugin which is 
installed with our GSS runtime package to make configuration easier, however the 
default installation normally meets customer requirements when Active Directory on 
Windows 2000 or 2003 is used as KDC.

Let me know if you would like to evaluate our Windows package with SASL.

Regards,

Tim.

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos