Re: windows browsers send ntlm instead of kerberos tokens

2005-08-30 Thread Julien ALLANOS
Quoting Markus [EMAIL PROTECTED]: Julien, as far as I am aware you can not use cnames. Normally the client/server uses a call to gss_import_name which canonicalises the hostname from the cname to the A record. If you capture the traffic on port 88 on the client you should see a TGS-REQ for

Re: kerberos authentication doesn't work agsint windows 2003 AD...

2005-08-30 Thread brian . joh
SASL and the GSS-API are not easy to use. They seem overly complicated to me, and the documentation is confusing. I could only get them working by looking at sample code. I first looked at some Samba code, but decided not to go that route. Openldap distributes a sample LDAP program which

Re: Java Pre-auth for Windows 2003 AD renamed accounts

2005-08-30 Thread Seema Malkani
Sun's implementation of Java GSS/Kerberos supports DES, 3DES, RC4-HMAC (ARCFOUR-HMAC), AES128, AES256 Kerberos encryption types. Support for RC4-HMAC Kerberos encryption type is available starting from Java SE 6 (Mustang). We are also looking into backporting support for RC4-HMAC to earlier

Re: Java Pre-auth for Windows 2003 AD renamed accounts

2005-08-30 Thread Seema Malkani
Sun's implementation of Java GSS/Kerberos includes Kerberos tools (kinit, klist, ktab) for Windows. Please download the latest build of Java SE 6 (Mustang). http://download.java.net/jdk6/binaries/ Seema Booker C. Bense wrote: -BEGIN PGP SIGNED MESSAGE- In article [EMAIL PROTECTED],

Re: Java Pre-auth for Windows 2003 AD renamed accounts

2005-08-30 Thread Douglas E. Engert
Seema Malkani wrote: Sun's implementation of Java GSS/Kerberos supports DES, 3DES, RC4-HMAC (ARCFOUR-HMAC), AES128, AES256 Kerberos encryption types. Support for RC4-HMAC Kerberos encryption type is available starting from Java SE 6 (Mustang). We are also looking into backporting support for

RE: Problems trying to authenticate Unix users via Active Directory

2005-08-30 Thread Smith, William E. \(Bill\), Jr.
Sorry, guess I was not clear. I had the Do not required Kerberos pre-authentication box checked for my AD user account and I was able to login into a Solaris 9 box using my AD credentials. With it unchecked, logins failed again. I can login to a Solaris 10 system using my AD credentials without

kinit issue

2005-08-30 Thread prashant sodhiya
Hi,  In MIT kerberos a kinit creates a credential file in /tmp, which is a world-writable directory. $ ls -l / drwxrwxrwt 9 bin bin3584 Aug 30 15:07 tmp I feel it can lead to Denial of Service attack if some other user can create a credential file as that of a

kinit issue

2005-08-30 Thread prashant sodhiya
Hi,  In MIT kerberos a kinit creates a credential file in /tmp, which is a world-writable directory. $ ls -l / drwxrwxrwt 9 bin bin3584 Aug 30 15:07 tmp I feel it can lead to Denial of Service attack if some other user can create a credential file as that of a

Kerberos Authentication against Active Directory in Java-Servlet

2005-08-30 Thread horser
Hi NG, I use Java 1.4.2 and a Servlet in which I do a password authentication against the Active Directory. It works fine but I have the problem if User has a password shorter then 6 characters the login will fail. (Preauthentication Error). The User has no problem if he log on an windows

Re: windows browsers send ntlm instead of kerberos tokens

2005-08-30 Thread Markus Moeller
Julian, I think creating a keytab with HTTP/[EMAIL PROTECTED] should be enough. Regards Markus Julien ALLANOS wrote: Quoting Markus [EMAIL PROTECTED]: Julien, as far as I am aware you can not use cnames. Normally the client/server uses a call to gss_import_name which canonicalises the

KDC doesn't appear to open a port

2005-08-30 Thread Maxwell Bottiger
Hi, I'm pretty new to kerberos, so please excuse me if this is a simple question. I'm using Fedora 4 with the preinstalled rpms as my source. I think the version is krb5-server-1.4.1-5. Anyway, the funny thing is, I can't see my KDC. If I start the services krb5admin and krb5kdc services,

Re: kerberos authentication doesn't work agsint windows 2003 AD...

2005-08-30 Thread Kent Wu
Hi guys, Thanks for all the inputs I've got so far. And I've figured out the reason behind it. The reason is that in the last ldap_sasl_bind_s() step, AD 2000 accepts the DN format like [EMAIL PROTECTED] however AD 2003 only accepts format like cn=Kent Wu,cn=Users,dc=blabla,dc=com. Not

Re: Kerberos Authentication against Active Directory in Java-Servlet

2005-08-30 Thread Seema Malkani
There are no restrictions to password length in Java. Check your Java Servlet code. Possibly you have specified a password size in the HTML file. Seema [EMAIL PROTECTED] wrote: Hi NG, I use Java 1.4.2 and a Servlet in which I do a password authentication against the Active Directory. It works

Re: Java Pre-auth for Windows 2003 AD renamed accounts

2005-08-30 Thread Seema Malkani
Support for RC4-HMAC Kerberos encryption type is available in Java SE (Mustang), starting from b35 onwards. Support for the new Pre-authentication types is available in Java SE 6 (Mustang) release, starting from b49 onwards. Please download the latest Mustang binary from:

Re: kinit issue

2005-08-30 Thread Russ Allbery
prashant sodhiya [EMAIL PROTECTED] writes:  In MIT kerberos a kinit creates a credential file in /tmp, which is a world-writable directory. $ ls -l / drwxrwxrwt 9 bin bin3584 Aug 30 15:07 tmp I feel it can lead to Denial of Service attack if some other user can

KDC failover

2005-08-30 Thread Jeff Aitken
Based on a discussion at work today, I'm confused as to how kerberos services work in the presence of a failure of one of the KDCs. I suspect I'm missing something obvious, but I can't quite figure it out. To start with, here's how I understand things to work in general: 1. The client sends a

Re: KDC failover

2005-08-30 Thread Jeffrey Hutzelman
On Tuesday, August 30, 2005 23:59:16 -0400 Jeff Aitken [EMAIL PROTECTED] wrote: Assuming I've got that part right, here's the part that's got me confused. In step #2, the AS generates a session key that will be used by the client during all future communication with the TGS; i.e., this is