Re: Windows Authentication

2016-03-07 Thread tomcat

On 07.03.2016 11:39, André Warnier (tomcat) wrote:

On 07.03.2016 06:10, Chanchal Kariwala wrote:

The article which suggested that NTLM is being used by Winlogon instead of
Kerberos :

http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header


So the token browser sends on first 401 starts from YHkG...
And the second token begins with YIIK1QYG



Check also this one :
https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iisie/



As you see, there are a lot of things to check, one by one.  That is because WIA (and 
Kerberos) are very fiddly, and even one little setting or circumstance can result in the 
thing not working (as in your case).


P.S. The mere volume of articles on this subject in Google (e.g. "kerberos and wia" or 
"kerberos and IE")

1) by itself makes it difficult to know which one to read and believe
2) indicates that this is a complex subject, with which a lot of people have 
problems

This list here is about Tomcat issues.  There is an SPNEGO authentication Valve in Tomcat, 
and there are certainly some people on this list with some knowledge of WIA/Kerberos, but 
such issues are probably not their main focus, or their main area of expertise.
You may have a bit more luck (or at least find more people focused on Windows 
authentication) on the Samba list for example.

Maybe try here : https://lists.samba.org/mailman/listinfo/samba
and supply all your previous information again, including the captured headers.
That would definitely increase your chances of receiving a helpful response.

It is not that we don't /want/ to help, but there are just too many external factors and 
settings which can play a role, that it is a bit overwhelming to try this one step remote 
from the problem.
If you do in the end identify a specific problem with the Tomcat SPNEGO Valve, don't 
hesitate to come back and ask for help here again.
Also, if you do find the solution, please post a short message to this list, so that maybe 
other people here with a similar issue could in the future find the solution in the list 
archives.

(I presume you have already searched these archives for similar issues ?)

Another thing, at a different level : if your main aim is to solve this issue quickly, 
then have a look at Jespa (https://www.ioplex.com/).

I can testify that Jespa works fautlessly in several installations which I did.
And just reading the User Manual may already give you some useful tips.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication

2016-03-07 Thread tomcat

On 07.03.2016 06:10, Chanchal Kariwala wrote:

The article which suggested that NTLM is being used by Winlogon instead of
Kerberos :

http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header

So the token browser sends on first 401 starts from YHkG...
And the second token begins with YIIK1QYG



Check also this one :
https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iisie/




Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Mon, Mar 7, 2016 at 10:19 AM, Chanchal Kariwala <
chanchal.kariw...@seclore.com> wrote:


In response to *George Stanchev*,
I tried with Chrome and IE 11, same behavior in both. And yes I tried
waffle, but in another webapp. Waffle does not prompt for the credentials..

In response to *André Warnier*,
I tired that to no avail :(

In response to *Felix Schumacher*,
It is not a problem with the webapp. I have tried both of what you asked.
Tomcat Keytab is authenticated successfully. And KRB debug
shows success for the keytab.

So here are my additional findings over the weekend.
Background - My test AD is virtual. My Domain Controller and client are
VMS.

1. *Windows Logon was using NTLM instead of Kerberos*

Some article led me to the following assumption :

When the browser receives WWW-Authenticate: Negotiate, it asks for the
token from the OS Cache. The OS Cache provides it a token that was obtained
via NTLM. The Server does not accept that since it specifically wants
Kerberos. And hence the browser asks for Credentials again and this time
the user is authenticated via Kerberos. And this token is accepted by the
Server.


2. *Windows Logon by IP Address uses NTLM*

I access the client machine (with tomcat) using RDP via the IP Address.
The following question on StackExchange indicates that in
such a scenario NTLM is used to logon to the system.

See :
http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain


3. *Kerberos Event Logging*

The next thing I was trying to figure was why Windows logon was using
NTLM. The above link suggests that there was no way of forcing
LSA to use Kerberos only. So now I am looking at the System events, which
might suggest which protocol is being used.

Also I enabled Kerberos event logging to see if there were any Kerberos
Errors.

See : https://support.microsoft.com/en-us/kb/262177


Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
​​
www.seclore.com



On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:


Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala:


I tries what you asked and I have observed the following

1. Browser sends a request for the resource
Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response
Headers

2. Browser sends a new request with the following in Request Headers
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg

Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
Response Headers

3. At this point the browser shows HTTP Basic Auth form and sends the
following in Headers
Authorization: Negotiate
YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
value, much much longer than the first one*)

Now the Server replies with HTTP 200 and the following in headers
WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly

So yes WIA is failing..
Can you help me out with the next step in debugging?


You can enable debugging for kerberos in the jvm and you can enable debug
logs for the SpnegoAuthenticator in tomcat to get more information.

To enable debug log messages in the jvm add

-Dsun.security.krb5.debug=true

to CATALINA_OPTS. The log messages will appear in catalina.out and are
quite verbose.

To enable debug log messages for SpnegoAuthenticator, add

org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE

to conf/logging.properties in your CATALINA_BASE directory.

Regards,
  Felix






Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 
wrote:

On 04.03.2016 07:16, Chanchal Kariwala wrote:


I am using Tomcat 8.0.32 and I have followed the guide given at


  -


https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
  -


https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

Windows AD Auth is working i.e. when I access the site, I am asked for
credentials and when I enter the correct credentials, the restricted
resource is displayed.

However my question is why the browser is asking for credentials? Why
isn't
it accessing TGT Cache in the OS 

Re: Windows Authentication

2016-03-06 Thread Chanchal Kariwala
The article which suggested that NTLM is being used by Winlogon instead of
Kerberos :

http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header

So the token browser sends on first 401 starts from YHkG...
And the second token begins with YIIK1QYG

Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Mon, Mar 7, 2016 at 10:19 AM, Chanchal Kariwala <
chanchal.kariw...@seclore.com> wrote:

> In response to *George Stanchev*,
> I tried with Chrome and IE 11, same behavior in both. And yes I tried
> waffle, but in another webapp. Waffle does not prompt for the credentials.
>
> In response to *André Warnier*,
> I tired that to no avail :(
>
> In response to *Felix Schumacher*,
> It is not a problem with the webapp. I have tried both of what you asked.
> Tomcat Keytab is authenticated successfully. And KRB debug
> shows success for the keytab.
>
> So here are my additional findings over the weekend.
> Background - My test AD is virtual. My Domain Controller and client are
> VMS.
>
> 1. *Windows Logon was using NTLM instead of Kerberos*
>
> Some article led me to the following assumption :
>
> When the browser receives WWW-Authenticate: Negotiate, it asks for the
> token from the OS Cache. The OS Cache provides it a token that was obtained
> via NTLM. The Server does not accept that since it specifically wants
> Kerberos. And hence the browser asks for Credentials again and this time
> the user is authenticated via Kerberos. And this token is accepted by the
> Server.
>
>
> 2. *Windows Logon by IP Address uses NTLM*
>
> I access the client machine (with tomcat) using RDP via the IP Address.
> The following question on StackExchange indicates that in
> such a scenario NTLM is used to logon to the system.
>
> See :
> http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain
>
>
> 3. *Kerberos Event Logging*
>
> The next thing I was trying to figure was why Windows logon was using
> NTLM. The above link suggests that there was no way of forcing
> LSA to use Kerberos only. So now I am looking at the System events, which
> might suggest which protocol is being used.
>
> Also I enabled Kerberos event logging to see if there were any Kerberos
> Errors.
>
> See : https://support.microsoft.com/en-us/kb/262177
>
>
> Thanks,
> Chanchal R. Kariwala
> Product Engineer
> Seclore Technology
> chanchal.kariw...@seclore.com
> ​​
> www.seclore.com
>
>
>
> On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>> Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala:
>>
>>> I tries what you asked and I have observed the following
>>>
>>> 1. Browser sends a request for the resource
>>> Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response
>>> Headers
>>>
>>> 2. Browser sends a new request with the following in Request Headers
>>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg
>>>
>>> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
>>> Response Headers
>>>
>>> 3. At this point the browser shows HTTP Basic Auth form and sends the
>>> following in Headers
>>> Authorization: Negotiate
>>> YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
>>> value, much much longer than the first one*)
>>>
>>> Now the Server replies with HTTP 200 and the following in headers
>>> WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
>>> Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly
>>>
>>> So yes WIA is failing..
>>> Can you help me out with the next step in debugging?
>>>
>> You can enable debugging for kerberos in the jvm and you can enable debug
>> logs for the SpnegoAuthenticator in tomcat to get more information.
>>
>> To enable debug log messages in the jvm add
>>
>> -Dsun.security.krb5.debug=true
>>
>> to CATALINA_OPTS. The log messages will appear in catalina.out and are
>> quite verbose.
>>
>> To enable debug log messages for SpnegoAuthenticator, add
>>
>> org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE
>>
>> to conf/logging.properties in your CATALINA_BASE directory.
>>
>> Regards,
>>  Felix
>>
>>
>>>
>>>
>>>
>>> Thanks,
>>> Chanchal R. Kariwala
>>> Product Engineer
>>> Seclore Technology
>>> chanchal.kariw...@seclore.com
>>> www.seclore.com
>>>
>>>
>>>
>>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 
>>> wrote:
>>>
>>> On 04.03.2016 07:16, Chanchal Kariwala wrote:

 I am using Tomcat 8.0.32 and I have followed the guide given at
>
>  -
>
>
> https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
>  -
>
>
> https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w
>
> Windows AD Auth is working i.e. when I access the site, I am asked for
> credentials and 

Re: Windows Authentication

2016-03-06 Thread Chanchal Kariwala
In response to *George Stanchev*,
I tried with Chrome and IE 11, same behavior in both. And yes I tried
waffle, but in another webapp. Waffle does not prompt for the credentials.

In response to *André Warnier*,
I tired that to no avail :(

In response to *Felix Schumacher*,
It is not a problem with the webapp. I have tried both of what you asked.
Tomcat Keytab is authenticated successfully. And KRB debug
shows success for the keytab.

So here are my additional findings over the weekend.
Background - My test AD is virtual. My Domain Controller and client are VMS.

1. *Windows Logon was using NTLM instead of Kerberos*

Some article led me to the following assumption :

When the browser receives WWW-Authenticate: Negotiate, it asks for the
token from the OS Cache. The OS Cache provides it a token that was obtained
via NTLM. The Server does not accept that since it specifically wants
Kerberos. And hence the browser asks for Credentials again and this time
the user is authenticated via Kerberos. And this token is accepted by the
Server.


2. *Windows Logon by IP Address uses NTLM*

I access the client machine (with tomcat) using RDP via the IP Address. The
following question on StackExchange indicates that in
such a scenario NTLM is used to logon to the system.

See :
http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain


3. *Kerberos Event Logging*

The next thing I was trying to figure was why Windows logon was using NTLM.
The above link suggests that there was no way of forcing
LSA to use Kerberos only. So now I am looking at the System events, which
might suggest which protocol is being used.

Also I enabled Kerberos event logging to see if there were any Kerberos
Errors.

See : https://support.microsoft.com/en-us/kb/262177


Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
​​
www.seclore.com



On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala:
>
>> I tries what you asked and I have observed the following
>>
>> 1. Browser sends a request for the resource
>> Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response
>> Headers
>>
>> 2. Browser sends a new request with the following in Request Headers
>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg
>>
>> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
>> Response Headers
>>
>> 3. At this point the browser shows HTTP Basic Auth form and sends the
>> following in Headers
>> Authorization: Negotiate
>> YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
>> value, much much longer than the first one*)
>>
>> Now the Server replies with HTTP 200 and the following in headers
>> WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
>> Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly
>>
>> So yes WIA is failing..
>> Can you help me out with the next step in debugging?
>>
> You can enable debugging for kerberos in the jvm and you can enable debug
> logs for the SpnegoAuthenticator in tomcat to get more information.
>
> To enable debug log messages in the jvm add
>
> -Dsun.security.krb5.debug=true
>
> to CATALINA_OPTS. The log messages will appear in catalina.out and are
> quite verbose.
>
> To enable debug log messages for SpnegoAuthenticator, add
>
> org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE
>
> to conf/logging.properties in your CATALINA_BASE directory.
>
> Regards,
>  Felix
>
>
>>
>>
>>
>> Thanks,
>> Chanchal R. Kariwala
>> Product Engineer
>> Seclore Technology
>> chanchal.kariw...@seclore.com
>> www.seclore.com
>>
>>
>>
>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 
>> wrote:
>>
>> On 04.03.2016 07:16, Chanchal Kariwala wrote:
>>>
>>> I am using Tomcat 8.0.32 and I have followed the guide given at

  -


 https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
  -


 https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

 Windows AD Auth is working i.e. when I access the site, I am asked for
 credentials and when I enter the correct credentials, the restricted
 resource is displayed.

 However my question is why the browser is asking for credentials? Why
 isn't
 it accessing TGT Cache in the OS to fetch the user's credentials?

 I have enabled Integrated Windows Auth in IE Settings. I have added the
 site in Intranet Sites and set "Logon by Current User" in Custom Level
 setting for Intranet.



 Hi.
>>>
>>> The real *key* to debugging such issues, is to use some plugin or add-on
>>> to the browser, to enable the capture and visualisation of the HTTP
>>> dialog
>>> back and forth between the browser and the server.
>>> Since you are using IE, I 

Re: Windows Authentication

2016-03-05 Thread Felix Schumacher

Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala:

I tries what you asked and I have observed the following

1. Browser sends a request for the resource
Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response
Headers

2. Browser sends a new request with the following in Request Headers
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg

Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
Response Headers

3. At this point the browser shows HTTP Basic Auth form and sends the
following in Headers
Authorization: Negotiate
YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
value, much much longer than the first one*)

Now the Server replies with HTTP 200 and the following in headers
WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly

So yes WIA is failing..
Can you help me out with the next step in debugging?
You can enable debugging for kerberos in the jvm and you can enable 
debug logs for the SpnegoAuthenticator in tomcat to get more information.


To enable debug log messages in the jvm add

-Dsun.security.krb5.debug=true

to CATALINA_OPTS. The log messages will appear in catalina.out and are 
quite verbose.


To enable debug log messages for SpnegoAuthenticator, add

org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE

to conf/logging.properties in your CATALINA_BASE directory.

Regards,
 Felix






Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 
wrote:


On 04.03.2016 07:16, Chanchal Kariwala wrote:


I am using Tomcat 8.0.32 and I have followed the guide given at

 -

https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
 -

https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

Windows AD Auth is working i.e. when I access the site, I am asked for
credentials and when I enter the correct credentials, the restricted
resource is displayed.

However my question is why the browser is asking for credentials? Why
isn't
it accessing TGT Cache in the OS to fetch the user's credentials?

I have enabled Integrated Windows Auth in IE Settings. I have added the
site in Intranet Sites and set "Logon by Current User" in Custom Level
setting for Intranet.




Hi.

The real *key* to debugging such issues, is to use some plugin or add-on
to the browser, to enable the capture and visualisation of the HTTP dialog
back and forth between the browser and the server.
Since you are using IE, I suggest "Fiddler2".
Install it, close your browser, re-open the browser, start Fiddler2 in
capture mode, and then do an access to the webserver.  When prompted for an
id/pw, enter them.
Then stop Fiddler2 and examine the HTTP exchanges, starting with your
initial request to the webserver.

You are correct in thinking that, normally, the login should happen
automatically in the background, and you should never see this browser
login dialog.
WIA authentication is a multiple-step process between the browser and the
webserver, and in the background between the webserver and a Domain
Controller.
That the login dialog appears in your case, means :
1) that the integrated WIA failed
2) that the Domain is configured to allow HTTP Basic authentication in a
second step, after WIA fails.  That is the login dialog that you see.

So, something is not working as it should in the WIA step.
But to know exactly what, requires examining the HTTP exchanges.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication

2016-03-04 Thread tomcat

On 04.03.2016 14:40, George Stanchev wrote:

It does not look like HTTP Basic. Did you try different browsers? IE, Chrome, 
FF? Do you get same behavior with all? Is the user logging in member of the 
domain your IWA is set up to?



Did you try /un/-checking the "Enable WIA authentication" checkbox in IE ?
(I know it sounds counter-intuitive, but try it).


If you set up a 3rd party IWA provider (such as Waffle), does it act the same 
on all 3 browsers? There was a recent issue with Waffle that one of my 
developers submitted that was dealing with similar issues [1]. You might want 
to go over that thread to see it can give you pointers.


[1] https://github.com/dblock/waffle/issues/268

-Original Message-
From: Chanchal Kariwala [mailto:chanchal.kariw...@seclore.com]
Sent: Friday, March 04, 2016 2:52 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Windows Authentication

But how does the browser decide on Basic Auth?

Usually 401 Response contains WWW-Authenticate: Basic realm="MyREALM" to 
indicate Basic Auth

Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:


On 04.03.2016 10:11, Chanchal Kariwala wrote:


I tries what you asked and I have observed the following

1. Browser sends a request for the resource Server replies with HTTP
401 and WWW-Authenticate: Negotiate in Response Headers



Fine.



2. Browser sends a new request with the following in Request Headers
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg



Also seems fine. (But difficult to tell, as these tokens are "opaque" by
design).

Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in

Response Headers



But this does not seem ok. It seems that the browser and server are
failing to agree on an authentication method, and dropping down to HTTP
Basic.


3. At this point the browser shows HTTP Basic Auth form and sends the

following in Headers
Authorization: Negotiate
YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
value, much much longer than the first one*)

Now the Server replies with HTTP 200 and the following in headers
WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly

So yes WIA is failing..
Can you help me out with the next step in debugging?



I think at this point, you need to go to your Windows network sysadmins,
with the information above, and ask them what is going on.
There are just too many possible reasons, in the Windows Domain
environment, why this could fail. (browser, browser version, workstation OS
version, browser settings, Domain Controller settings, Domain networkn
policies, membership of Domain or not, etc.).





Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

On 04.03.2016 07:16, Chanchal Kariwala wrote:


I am using Tomcat 8.0.32 and I have followed the guide given at


  -


https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
  -


https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

Windows AD Auth is working i.e. when I access the site, I am asked for
credentials and when I enter the correct credentials, the restricted
resource is displayed.

However my question is why the browser is asking for credentials? Why
isn't
it accessing TGT Cache in the OS to fetch the user's credentials?

I have enabled Integrated Windows Auth in IE Settings. I have added the
site in Intranet Sites and set "Logon by Current User" in Custom Level
setting for Intranet.



Hi.


The real *key* to debugging such issues, is to use some plugin or add-on
to the browser, to enable the capture and visualisation of the HTTP
dialog
back and forth between the browser and the server.
Since you are using IE, I suggest "Fiddler2".
Install it, close your browser, re-open the browser, start Fiddler2 in
capture mode, and then do an access to the webserver.  When prompted for
an
id/pw, enter them.
Then stop Fiddler2 and examine the HTTP exchanges, starting with your
initial request to the webserver.

You are correct in thinking that, normally, the login should happen
automatically in the background, and you should never see this browser
login dialog.
WIA authentication is a multiple-step process between the browser and the
webserver, and in the background between the webserver and a Domain
Controller.
That the login dialog appears in your case, means :
1) that the integrated WIA failed
2) that the Domain is configured to allow HTTP Basic authentication in a
second step, after WIA fails.  That is the login dialog that you see.

So, something is not work

RE: Windows Authentication

2016-03-04 Thread George Stanchev
It does not look like HTTP Basic. Did you try different browsers? IE, Chrome, 
FF? Do you get same behavior with all? Is the user logging in member of the 
domain your IWA is set up to?

If you set up a 3rd party IWA provider (such as Waffle), does it act the same 
on all 3 browsers? There was a recent issue with Waffle that one of my 
developers submitted that was dealing with similar issues [1]. You might want 
to go over that thread to see it can give you pointers.


[1] https://github.com/dblock/waffle/issues/268

-Original Message-
From: Chanchal Kariwala [mailto:chanchal.kariw...@seclore.com] 
Sent: Friday, March 04, 2016 2:52 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Windows Authentication

But how does the browser decide on Basic Auth?

Usually 401 Response contains WWW-Authenticate: Basic realm="MyREALM" to 
indicate Basic Auth

Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:

> On 04.03.2016 10:11, Chanchal Kariwala wrote:
>
>> I tries what you asked and I have observed the following
>>
>> 1. Browser sends a request for the resource Server replies with HTTP 
>> 401 and WWW-Authenticate: Negotiate in Response Headers
>>
>
> Fine.
>
>
>> 2. Browser sends a new request with the following in Request Headers
>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg
>>
>>
> Also seems fine. (But difficult to tell, as these tokens are "opaque" by
> design).
>
> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
>> Response Headers
>>
>>
> But this does not seem ok. It seems that the browser and server are
> failing to agree on an authentication method, and dropping down to HTTP
> Basic.
>
>
> 3. At this point the browser shows HTTP Basic Auth form and sends the
>> following in Headers
>> Authorization: Negotiate
>> YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
>> value, much much longer than the first one*)
>>
>> Now the Server replies with HTTP 200 and the following in headers
>> WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
>> Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly
>>
>> So yes WIA is failing..
>> Can you help me out with the next step in debugging?
>>
>>
> I think at this point, you need to go to your Windows network sysadmins,
> with the information above, and ask them what is going on.
> There are just too many possible reasons, in the Windows Domain
> environment, why this could fail. (browser, browser version, workstation OS
> version, browser settings, Domain Controller settings, Domain networkn
> policies, membership of Domain or not, etc.).
>
>
>>
>>
>> Thanks,
>> Chanchal R. Kariwala
>> Product Engineer
>> Seclore Technology
>> chanchal.kariw...@seclore.com
>> www.seclore.com
>>
>>
>>
>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <a...@ice-sa.com>
>> wrote:
>>
>> On 04.03.2016 07:16, Chanchal Kariwala wrote:
>>>
>>> I am using Tomcat 8.0.32 and I have followed the guide given at
>>>>
>>>>  -
>>>>
>>>>
>>>> https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
>>>>  -
>>>>
>>>>
>>>> https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w
>>>>
>>>> Windows AD Auth is working i.e. when I access the site, I am asked for
>>>> credentials and when I enter the correct credentials, the restricted
>>>> resource is displayed.
>>>>
>>>> However my question is why the browser is asking for credentials? Why
>>>> isn't
>>>> it accessing TGT Cache in the OS to fetch the user's credentials?
>>>>
>>>> I have enabled Integrated Windows Auth in IE Settings. I have added the
>>>> site in Intranet Sites and set "Logon by Current User" in Custom Level
>>>> setting for Intranet.
>>>>
>>>>
>>>>
>>>> Hi.
>>>
>>> The real *key* to debugging such issues, is to use some plugin or add-on
>>> to the browser, to enable the capture and visualisation of the HTTP
>>> dialog
>>> back and forth between the browser and the server.
>>> Since you are using IE, I suggest "Fiddler2".
>>> Install it, close your browser, re-open

Re: Windows Authentication

2016-03-04 Thread Chanchal Kariwala
But how does the browser decide on Basic Auth?

Usually 401 Response contains WWW-Authenticate: Basic realm="MyREALM" to
indicate Basic Auth

Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) 
wrote:

> On 04.03.2016 10:11, Chanchal Kariwala wrote:
>
>> I tries what you asked and I have observed the following
>>
>> 1. Browser sends a request for the resource
>> Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response
>> Headers
>>
>
> Fine.
>
>
>> 2. Browser sends a new request with the following in Request Headers
>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg
>>
>>
> Also seems fine. (But difficult to tell, as these tokens are "opaque" by
> design).
>
> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
>> Response Headers
>>
>>
> But this does not seem ok. It seems that the browser and server are
> failing to agree on an authentication method, and dropping down to HTTP
> Basic.
>
>
> 3. At this point the browser shows HTTP Basic Auth form and sends the
>> following in Headers
>> Authorization: Negotiate
>> YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
>> value, much much longer than the first one*)
>>
>> Now the Server replies with HTTP 200 and the following in headers
>> WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
>> Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly
>>
>> So yes WIA is failing..
>> Can you help me out with the next step in debugging?
>>
>>
> I think at this point, you need to go to your Windows network sysadmins,
> with the information above, and ask them what is going on.
> There are just too many possible reasons, in the Windows Domain
> environment, why this could fail. (browser, browser version, workstation OS
> version, browser settings, Domain Controller settings, Domain networkn
> policies, membership of Domain or not, etc.).
>
>
>>
>>
>> Thanks,
>> Chanchal R. Kariwala
>> Product Engineer
>> Seclore Technology
>> chanchal.kariw...@seclore.com
>> www.seclore.com
>>
>>
>>
>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 
>> wrote:
>>
>> On 04.03.2016 07:16, Chanchal Kariwala wrote:
>>>
>>> I am using Tomcat 8.0.32 and I have followed the guide given at

  -


 https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
  -


 https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

 Windows AD Auth is working i.e. when I access the site, I am asked for
 credentials and when I enter the correct credentials, the restricted
 resource is displayed.

 However my question is why the browser is asking for credentials? Why
 isn't
 it accessing TGT Cache in the OS to fetch the user's credentials?

 I have enabled Integrated Windows Auth in IE Settings. I have added the
 site in Intranet Sites and set "Logon by Current User" in Custom Level
 setting for Intranet.



 Hi.
>>>
>>> The real *key* to debugging such issues, is to use some plugin or add-on
>>> to the browser, to enable the capture and visualisation of the HTTP
>>> dialog
>>> back and forth between the browser and the server.
>>> Since you are using IE, I suggest "Fiddler2".
>>> Install it, close your browser, re-open the browser, start Fiddler2 in
>>> capture mode, and then do an access to the webserver.  When prompted for
>>> an
>>> id/pw, enter them.
>>> Then stop Fiddler2 and examine the HTTP exchanges, starting with your
>>> initial request to the webserver.
>>>
>>> You are correct in thinking that, normally, the login should happen
>>> automatically in the background, and you should never see this browser
>>> login dialog.
>>> WIA authentication is a multiple-step process between the browser and the
>>> webserver, and in the background between the webserver and a Domain
>>> Controller.
>>> That the login dialog appears in your case, means :
>>> 1) that the integrated WIA failed
>>> 2) that the Domain is configured to allow HTTP Basic authentication in a
>>> second step, after WIA fails.  That is the login dialog that you see.
>>>
>>> So, something is not working as it should in the WIA step.
>>> But to know exactly what, requires examining the HTTP exchanges.
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Windows Authentication

2016-03-04 Thread tomcat

On 04.03.2016 10:11, Chanchal Kariwala wrote:

I tries what you asked and I have observed the following

1. Browser sends a request for the resource
Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response
Headers


Fine.



2. Browser sends a new request with the following in Request Headers
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg



Also seems fine. (But difficult to tell, as these tokens are "opaque" by 
design).


Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
Response Headers



But this does not seem ok. It seems that the browser and server are failing to agree on an 
authentication method, and dropping down to HTTP Basic.




3. At this point the browser shows HTTP Basic Auth form and sends the
following in Headers
Authorization: Negotiate
YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
value, much much longer than the first one*)

Now the Server replies with HTTP 200 and the following in headers
WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly

So yes WIA is failing..
Can you help me out with the next step in debugging?



I think at this point, you need to go to your Windows network sysadmins, with the 
information above, and ask them what is going on.
There are just too many possible reasons, in the Windows Domain environment, why this 
could fail. (browser, browser version, workstation OS version, browser settings, Domain 
Controller settings, Domain networkn policies, membership of Domain or not, etc.).






Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 
wrote:


On 04.03.2016 07:16, Chanchal Kariwala wrote:


I am using Tomcat 8.0.32 and I have followed the guide given at

 -

https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
 -

https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

Windows AD Auth is working i.e. when I access the site, I am asked for
credentials and when I enter the correct credentials, the restricted
resource is displayed.

However my question is why the browser is asking for credentials? Why
isn't
it accessing TGT Cache in the OS to fetch the user's credentials?

I have enabled Integrated Windows Auth in IE Settings. I have added the
site in Intranet Sites and set "Logon by Current User" in Custom Level
setting for Intranet.




Hi.

The real *key* to debugging such issues, is to use some plugin or add-on
to the browser, to enable the capture and visualisation of the HTTP dialog
back and forth between the browser and the server.
Since you are using IE, I suggest "Fiddler2".
Install it, close your browser, re-open the browser, start Fiddler2 in
capture mode, and then do an access to the webserver.  When prompted for an
id/pw, enter them.
Then stop Fiddler2 and examine the HTTP exchanges, starting with your
initial request to the webserver.

You are correct in thinking that, normally, the login should happen
automatically in the background, and you should never see this browser
login dialog.
WIA authentication is a multiple-step process between the browser and the
webserver, and in the background between the webserver and a Domain
Controller.
That the login dialog appears in your case, means :
1) that the integrated WIA failed
2) that the Domain is configured to allow HTTP Basic authentication in a
second step, after WIA fails.  That is the login dialog that you see.

So, something is not working as it should in the WIA step.
But to know exactly what, requires examining the HTTP exchanges.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication

2016-03-04 Thread Chanchal Kariwala
I tries what you asked and I have observed the following

1. Browser sends a request for the resource
Server replies with HTTP 401 and WWW-Authenticate: Negotiate in Response
Headers

2. Browser sends a new request with the following in Request Headers
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg

Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
Response Headers

3. At this point the browser shows HTTP Basic Auth form and sends the
following in Headers
Authorization: Negotiate
YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
value, much much longer than the first one*)

Now the Server replies with HTTP 200 and the following in headers
WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly

So yes WIA is failing..
Can you help me out with the next step in debugging?




Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 
wrote:

> On 04.03.2016 07:16, Chanchal Kariwala wrote:
>
>> I am using Tomcat 8.0.32 and I have followed the guide given at
>>
>> -
>>
>> https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
>> -
>>
>> https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w
>>
>> Windows AD Auth is working i.e. when I access the site, I am asked for
>> credentials and when I enter the correct credentials, the restricted
>> resource is displayed.
>>
>> However my question is why the browser is asking for credentials? Why
>> isn't
>> it accessing TGT Cache in the OS to fetch the user's credentials?
>>
>> I have enabled Integrated Windows Auth in IE Settings. I have added the
>> site in Intranet Sites and set "Logon by Current User" in Custom Level
>> setting for Intranet.
>>
>>
>>
> Hi.
>
> The real *key* to debugging such issues, is to use some plugin or add-on
> to the browser, to enable the capture and visualisation of the HTTP dialog
> back and forth between the browser and the server.
> Since you are using IE, I suggest "Fiddler2".
> Install it, close your browser, re-open the browser, start Fiddler2 in
> capture mode, and then do an access to the webserver.  When prompted for an
> id/pw, enter them.
> Then stop Fiddler2 and examine the HTTP exchanges, starting with your
> initial request to the webserver.
>
> You are correct in thinking that, normally, the login should happen
> automatically in the background, and you should never see this browser
> login dialog.
> WIA authentication is a multiple-step process between the browser and the
> webserver, and in the background between the webserver and a Domain
> Controller.
> That the login dialog appears in your case, means :
> 1) that the integrated WIA failed
> 2) that the Domain is configured to allow HTTP Basic authentication in a
> second step, after WIA fails.  That is the login dialog that you see.
>
> So, something is not working as it should in the WIA step.
> But to know exactly what, requires examining the HTTP exchanges.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Windows Authentication

2016-03-03 Thread tomcat

On 04.03.2016 07:16, Chanchal Kariwala wrote:

I am using Tomcat 8.0.32 and I have followed the guide given at

-

https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
-

https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

Windows AD Auth is working i.e. when I access the site, I am asked for
credentials and when I enter the correct credentials, the restricted
resource is displayed.

However my question is why the browser is asking for credentials? Why isn't
it accessing TGT Cache in the OS to fetch the user's credentials?

I have enabled Integrated Windows Auth in IE Settings. I have added the
site in Intranet Sites and set "Logon by Current User" in Custom Level
setting for Intranet.




Hi.

The real *key* to debugging such issues, is to use some plugin or add-on to the browser, 
to enable the capture and visualisation of the HTTP dialog back and forth between the 
browser and the server.

Since you are using IE, I suggest "Fiddler2".
Install it, close your browser, re-open the browser, start Fiddler2 in capture mode, and 
then do an access to the webserver.  When prompted for an id/pw, enter them.
Then stop Fiddler2 and examine the HTTP exchanges, starting with your initial request to 
the webserver.


You are correct in thinking that, normally, the login should happen automatically in the 
background, and you should never see this browser login dialog.
WIA authentication is a multiple-step process between the browser and the webserver, and 
in the background between the webserver and a Domain Controller.

That the login dialog appears in your case, means :
1) that the integrated WIA failed
2) that the Domain is configured to allow HTTP Basic authentication in a second step, 
after WIA fails.  That is the login dialog that you see.


So, something is not working as it should in the WIA step.
But to know exactly what, requires examining the HTTP exchanges.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows authentication : outdated link

2015-03-13 Thread Konstantin Kolinko
2015-03-13 15:04 GMT+03:00 André Warnier a...@ice-sa.com:
 Hi.

 Errata :

 In the page
 http://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#References
 (and also in the corresponding Tomcat 7 page), the link to

 Geronimo configuration for Windows authentication

 leads to :

 https://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html#UsingSpengoingeronimo-SettinguptheActiveDirectoryDomainController

 which returns :

 The requested URL
 /confluence/display/GMOxDOC21/using-spengo-in-geronimo.html was not found on
 this server.

 (neither does it work if one replaces the spengo parts by spnego..)


Apparently they replaced '-' with '+' and have lost the .html suffix.

https://cwiki.apache.org/confluence/display/GMOxDOC21/Using+SPNEGO+in+Geronimo#UsingSPNEGOinGeronimo-SettinguptheDomainControllerMachine

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows authentication : outdated link

2015-03-13 Thread Konstantin Kolinko
2015-03-13 15:13 GMT+03:00 Konstantin Kolinko knst.koli...@gmail.com:
 2015-03-13 15:04 GMT+03:00 André Warnier a...@ice-sa.com:
 Hi.

 Errata :

 In the page
 http://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#References
 (and also in the corresponding Tomcat 7 page), the link to

 Geronimo configuration for Windows authentication

 leads to :

 https://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html#UsingSpengoingeronimo-SettinguptheActiveDirectoryDomainController

 which returns :

 The requested URL
 /confluence/display/GMOxDOC21/using-spengo-in-geronimo.html was not found on
 this server.

 (neither does it work if one replaces the spengo parts by spnego..)


 Apparently they replaced '-' with '+' and have lost the .html suffix.

 https://cwiki.apache.org/confluence/display/GMOxDOC21/Using+SPNEGO+in+Geronimo#UsingSPNEGOinGeronimo-SettinguptheDomainControllerMachine

I updated the docs in Tomcat 9/8/7.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Windows Authentication on Tomcat 7.0.37 and JRE 7u13 / 64-bit

2013-03-01 Thread Chris Fors


All systems are  domain-joined to a mature IT Lab and the issue is with the 
Tomcat server configuration as it should load the krb5.ini and or jaas.conf and 
activity should be observable on the Web server - whether or not any error is 
generated.  It is not clear to me what the design load process / order of the 
call stack should be in the SPNEGO Authentication design.  This would help 
focus on where the issue is. I ran Process Monitor
during a Network Client PC TCP session to the Tomcat Web Server as well as
during start of the Tomcat Web service.  

During either of these  I don’t observe any calls to jaas.conf, or
krb5.ini.

What should initiate loading
of these and at what point should they load?



Observation Notes:

Process Monitor for Tomcat7.exe when browsing to 
http://server/SPNEGOAuthTest.jsp shows in summary

TCP Accept: Server - PC


TCP Receive: Server -
PC

CreateFile:  .\Tomcat7.0\webapps\ROOT\SPNEGOAuthTest.jsp

QueryNetworkOpenInformationFile:

CloseFile:

CreateFile:...

CreateFile: .\ \_\org\apache\jsp\SPNEGOAuthTest_jsp.class

CloseFole . \ \_\org\apache\jsp\SPNEGOAuthTest_jsp.class

...

TCP Send:  Server - PC

In the SPNEGOAuthTest.jsp
HTML response: 

  request.getRemoteUser()
response shows value of “Nul”

  request.getRemoteAddr()
does show the IP address of the PC



Process Monitor during Tomcat
Service start - 

Calls are shown to 

   .\conf\server.xml

   mbeans-descriptors.xml

   .\conf\tomcat-users.xml

   .\conf\context.xml

   .\conf\web.xml

Again no calls to
jaas.conf, or krb5.ini


  Date: Thu, 28 Feb 2013 06:42:35 -0800
 From: ma...@apache.org
 To: users@tomcat.apache.org
 Subject: Re: Windows Authentication on Tomcat 7.0.37 and JRE 7u13 / 64-bit
 
 On 28/02/2013 02:18, Chris Fors wrote:
  Trying to get Windows
  Authentication operational using the Tomcat Built-in method.  Implemented 
  the following but not
  observed any Windows / Kerberos authentication occuring:
 
  -
  Domain joined
  windows member server
 
  -
  Domain service
  account
 
  -
  Delegated SPN for
  HTTP protocol on the member server to the service account
 
  -
  Generated keytab
  file for the service account and saved in $catalina.base\conf folder
 
  -
  Created Valve in context.xml of className 
  org.apache.catalina.authenticator.SpnegoAuthenticator
 
  -
  Created krb5.ini and
  saved in $catalina.base\conf folder
 
  -
  Created jaas.conf and
  saved in $catalina.base\conf folder
 
 
 
  After this still no observed
  effect on logon authentications – all still apparently anonymous.
 
 As expected from what you have described.
 
 If there are no security constraints on a resource, Tomcat isn't going 
 to require authentication.
 
 
Anyone had success with this ?
 
 Yes. I have a set of test VMs (1 domain controller, 1 Tomcat server and 
 1 client) where this feature works.
 
  Any ideas on what is missing?Is there a good way to
  debug the process?
 
 See above. I'd expect to see some changes to the webapp.
 
 Mark
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
  

Re: Windows Authentication on Tomcat 7.0.37 and JRE 7u13 / 64-bit

2013-02-28 Thread André Warnier

Chris Fors wrote:


Trying to get Windows
Authentication operational using the Tomcat Built-in method.  Implemented the 
following but not
observed any Windows / Kerberos authentication occuring: 

-  
Domain joined

windows member server

-  
Domain service

account

-  
Delegated SPN for

HTTP protocol on the member server to the service account

-  
Generated keytab

file for the service account and saved in $catalina.base\conf folder

-  
Created Valve in context.xml of className org.apache.catalina.authenticator.SpnegoAuthenticator 

-  
Created krb5.ini and
saved in $catalina.base\conf folder 

-  
Created jaas.conf and
saved in $catalina.base\conf folder 

 


After this still no observed
effect on logon authentications – all still apparently anonymous.  


 Anyone had success with this ? Any ideas on what is missing?Is there a good 
way to
debug the process? 





What is the OS platform ?

To debug the process : other than what you already did above, a network trace  with 
Wireshark or similar ? (should be SMB exchanges I suppose)


Another couple of questions :
- is the client workstation that accesses the Tomcat server, itself in the Domain to which 
you are trying to authenticate ?
- from the point of view of that workstation and its browser, is that Tomcat server 
considered as inside the Domain, or at least trusted ?

(because if not, then the browser will not even /try/ to use WIA authentication)



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication on Tomcat 7.0.37 and JRE 7u13 / 64-bit

2013-02-28 Thread Mark Thomas

On 28/02/2013 02:18, Chris Fors wrote:

Trying to get Windows
Authentication operational using the Tomcat Built-in method.  Implemented the 
following but not
observed any Windows / Kerberos authentication occuring:

-
Domain joined
windows member server

-
Domain service
account

-
Delegated SPN for
HTTP protocol on the member server to the service account

-
Generated keytab
file for the service account and saved in $catalina.base\conf folder

-
Created Valve in context.xml of className 
org.apache.catalina.authenticator.SpnegoAuthenticator

-
Created krb5.ini and
saved in $catalina.base\conf folder

-
Created jaas.conf and
saved in $catalina.base\conf folder



After this still no observed
effect on logon authentications – all still apparently anonymous.


As expected from what you have described.

If there are no security constraints on a resource, Tomcat isn't going 
to require authentication.




  Anyone had success with this ?


Yes. I have a set of test VMs (1 domain controller, 1 Tomcat server and 
1 client) where this feature works.



Any ideas on what is missing?Is there a good way to
debug the process?


See above. I'd expect to see some changes to the webapp.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-04-11 Thread Tim Whittington
On Mon, Mar 28, 2011 at 7:26 AM, Stefan Mayr ste...@mayr-stefan.de wrote:
 Hello everybody,

 as many others before we wanted to do single-sign-on for intranet web
 applications using integrated windows authentication (negotiate because IE
 sometimes tries NTLM instead of using plain kerberos - breaking all our
 kerberos-only experiments).

 We thought that IIS would be the best choice for integrated windows
 authentication and we could pass the user via AJP (using mod_jk) to our
 tomcat instances.

 Our setup:
 - Windows 2008 R2 using IIS 7.5 (64bit)
 - mod_jk 1.2.31
 - Oracle Java 1.6 U24
 - Tomcat 6.0.32

 At first glance using tomcatAuthentication=false worked as expected. We got
 the remote user and started deploying an application. End of happiness - the
 application complained about a missing user-agent. That header was not
 passed to tomcat when authentication was enabled on IIS.

 Some research revealed Bug 47679 - Not all headers get passed to Tomcat
 server from isapi_redirect.dll
 (https://issues.apache.org/bugzilla/show_bug.cgi?id=47679)

 Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator /
 integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318).
 The last comment links a new Windows Authentication How-To from Mark Thomas.
 Looks like we have already tried almost all proposed solutions:

 - IIS + mod_jk:
  tried but stuck in Bug 47679. Also tried ARR to pass the user name
  as a request header from IIS to Tomcat without success
 - Apache mod_ntlm: used it and we replaced it by the much more stable
  mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default)
 - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit
  plattform - we couldn't get stability problems solved on Apache 2.2
  and 64bit Linux. No ongoing development.
 - Apache mod_auth_sspi: till now in internal use for a very small
  project (works just fine), not sure about the future. Although
  there seems to be some new activity on 1.0.5 beta
 - Waffle: found it on thursday and it is on my our todo-list for
  testing it next week

 Any chances to get Bug 47679 solved? How can we help (we are admins, no
 devs)?
 What solutions have you deployed? Recommendations?

I've committed a fix for Bug 47679, which I hope will resolve the
issues people have been having using the ISAPI redirector in an
extension only mode.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-04-04 Thread André Warnier

Stefan Mayr wrote:


Native SPNEGO in Tomcat sounds great. Waiting a little while depends on 
your scale of little. Is there already some development we can follow? 
Will this use Java GSS? I never figured out how to configure this with 
Tomcat.



If you are in a hurry, you may want to have a look at Jespa : www.ioplex.com.
Have it installed at numerous customers sites and works great.

About the sequence of rewrite/forward with IIS, have a look at isapi_rewrite :
http://www.helicontech.com/isapi_rewrite/doc/

It can pick up the user's Windows domain user-id, and pass it on as a HTTP 
header.
You would then need a simple servlet filter at the Tomcat level, to pick up the content of 
this header and use it as the authenticated Tomcat user-id.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-29 Thread Mark Thomas
On 28/03/2011 22:31, Stefan Mayr wrote:
 Native SPNEGO in Tomcat sounds great. Waiting a little while depends on
 your scale of little. Is there already some development we can follow?
 Will this use Java GSS? I never figured out how to configure this with
 Tomcat.

little hopefully means the next week or so in a 7.0.12 release. I have
a handful of things I need/want to get into 7.0.12 and SPNEGO is one of
them.

Having spent more time than I want to think about and having lost count
of the number of times I re-installed Windows 2k8 server to test this, I
finally got this working a few minutes ago. The current code is *very*
rough and ready and it only does authentication, not authorisation so I
still have some work to do.

The solution is based on ideas from Spring Security's Kerberos extension
and the most recent patches attached to bug 48685.

I'll be committing an initial implementation once I have cleaned up the
code a bit and then I'll build on that to add authorisation, more
configuration etc.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-29 Thread Mark Thomas
On 29/03/2011 15:20, Mark Thomas wrote:
 On 28/03/2011 22:31, Stefan Mayr wrote:
 Native SPNEGO in Tomcat sounds great. Waiting a little while depends on
 your scale of little. Is there already some development we can follow?
 Will this use Java GSS? I never figured out how to configure this with
 Tomcat.
 
 little hopefully means the next week or so in a 7.0.12 release. I have
 a handful of things I need/want to get into 7.0.12 and SPNEGO is one of
 them.
 
 Having spent more time than I want to think about and having lost count
 of the number of times I re-installed Windows 2k8 server to test this, I
 finally got this working a few minutes ago. The current code is *very*
 rough and ready and it only does authentication, not authorisation so I
 still have some work to do.
 
 The solution is based on ideas from Spring Security's Kerberos extension
 and the most recent patches attached to bug 48685.
 
 I'll be committing an initial implementation once I have cleaned up the
 code a bit and then I'll build on that to add authorisation, more
 configuration etc.

The first part just got committed [1]. More to follow over the next day
or so.

Mark

[1] http://svn.apache.org/viewvc?rev=1086683view=rev

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-29 Thread Borut Hadžialić
Would adding support for client credential delegation be out of scope
for this implementation or not?

Client credential delegation is when you use the spnego token
construct a javax.security.auth.Subject instance that represents the
client - which the server side application can use this to impersonate
the client (eg. connect to some Kerberized database as the client that
sent the request, or consume some other kerberized service as the
client).

The code for creating such a Subject would be something like this:

GSSContext context =
GSSManager.getInstance().createContext((GSSCredential) null);
context.acceptSecContext(...);

//check if the credentials can be delegated
if (!context.getCredDelegState()) {

  //get the delegated credentials from the calling peer...
  GSSCredential clientCred = context.getDelegCred();

  //Create a Subject out of the delegated credentials.
  //With this Subject the application server can impersonate the
client that sent the request.
  Subject clientSubject =
com.sun.security.jgss.GSSUtil.createSubject(context.getSrcName(),
clientCred);
}

//Store the clientSubject somewhere - maybe to the HttpServletRequest?

I am sure this would be useful for some applications - for example the
one that we are currently developing needs functionality like this.

On Tue, Mar 29, 2011 at 9:09 PM, Mark Thomas ma...@apache.org wrote:
 On 29/03/2011 15:20, Mark Thomas wrote:
 On 28/03/2011 22:31, Stefan Mayr wrote:
 Native SPNEGO in Tomcat sounds great. Waiting a little while depends on
 your scale of little. Is there already some development we can follow?
 Will this use Java GSS? I never figured out how to configure this with
 Tomcat.

 little hopefully means the next week or so in a 7.0.12 release. I have
 a handful of things I need/want to get into 7.0.12 and SPNEGO is one of
 them.

 Having spent more time than I want to think about and having lost count
 of the number of times I re-installed Windows 2k8 server to test this, I
 finally got this working a few minutes ago. The current code is *very*
 rough and ready and it only does authentication, not authorisation so I
 still have some work to do.

 The solution is based on ideas from Spring Security's Kerberos extension
 and the most recent patches attached to bug 48685.

 I'll be committing an initial implementation once I have cleaned up the
 code a bit and then I'll build on that to add authorisation, more
 configuration etc.

 The first part just got committed [1]. More to follow over the next day
 or so.

 Mark

 [1] http://svn.apache.org/viewvc?rev=1086683view=rev

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org





-- 
Why?
Because YES!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-29 Thread Borut Hadžialić
Whoops, i reversed the condition of the if statement, it should be:

//check if the credentials can be delegated
if (context.getCredDelegState()) {
...
}

On Tue, Mar 29, 2011 at 9:47 PM, Borut Hadžialić
borut.hadzia...@gmail.com wrote:
 Would adding support for client credential delegation be out of scope
 for this implementation or not?

 Client credential delegation is when you use the spnego token
 construct a javax.security.auth.Subject instance that represents the
 client - which the server side application can use this to impersonate
 the client (eg. connect to some Kerberized database as the client that
 sent the request, or consume some other kerberized service as the
 client).

 The code for creating such a Subject would be something like this:

 GSSContext context =
 GSSManager.getInstance().createContext((GSSCredential) null);
 context.acceptSecContext(...);

 //check if the credentials can be delegated
 if (!context.getCredDelegState()) {

  //get the delegated credentials from the calling peer...
  GSSCredential clientCred = context.getDelegCred();

  //Create a Subject out of the delegated credentials.
  //With this Subject the application server can impersonate the
 client that sent the request.
  Subject clientSubject =
 com.sun.security.jgss.GSSUtil.createSubject(context.getSrcName(),
 clientCred);
 }

 //Store the clientSubject somewhere - maybe to the HttpServletRequest?

 I am sure this would be useful for some applications - for example the
 one that we are currently developing needs functionality like this.

 On Tue, Mar 29, 2011 at 9:09 PM, Mark Thomas ma...@apache.org wrote:
 On 29/03/2011 15:20, Mark Thomas wrote:
 On 28/03/2011 22:31, Stefan Mayr wrote:
 Native SPNEGO in Tomcat sounds great. Waiting a little while depends on
 your scale of little. Is there already some development we can follow?
 Will this use Java GSS? I never figured out how to configure this with
 Tomcat.

 little hopefully means the next week or so in a 7.0.12 release. I have
 a handful of things I need/want to get into 7.0.12 and SPNEGO is one of
 them.

 Having spent more time than I want to think about and having lost count
 of the number of times I re-installed Windows 2k8 server to test this, I
 finally got this working a few minutes ago. The current code is *very*
 rough and ready and it only does authentication, not authorisation so I
 still have some work to do.

 The solution is based on ideas from Spring Security's Kerberos extension
 and the most recent patches attached to bug 48685.

 I'll be committing an initial implementation once I have cleaned up the
 code a bit and then I'll build on that to add authorisation, more
 configuration etc.

 The first part just got committed [1]. More to follow over the next day
 or so.

 Mark

 [1] http://svn.apache.org/viewvc?rev=1086683view=rev

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org





 --
 Why?
 Because YES!




-- 
Why?
Because YES!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-29 Thread Mark Thomas
On 29/03/2011 20:47, Borut Hadžialić wrote:
 Would adding support for client credential delegation be out of scope
 for this implementation or not?

It is in scope with the caveat - as always - that it depends on what the
final implementation looks like. I do know (from debug logging) that
right now tokens do not allow delegation. I suspect the hardest part of
implementing this will be figuring out what config needs tweaking to
allow that.

 //Store the clientSubject somewhere - maybe to the HttpServletRequest?

That needs a little more thought. I am leaning towards a request
attribute at the moment unless I can find a way to get it into the
result of getUserPrincipal() (which I don't think I can without
requiring a cast to a Tomcat internal class which is just horrible).

 I am sure this would be useful for some applications - for example the
 one that we are currently developing needs functionality like this.

Testing help always appreciated if you are happy running the latest
7.0.x release (this should be in 7.0.12 which I plan to start releasing
just as soon as I finish everything on my todo list).

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-29 Thread Borut Hadžialić
On Tue, Mar 29, 2011 at 9:57 PM, Mark Thomas ma...@apache.org wrote:
 It is in scope with the caveat - as always - that it depends on what the
 final implementation looks like. I do know (from debug logging) that
 right now tokens do not allow delegation. I suspect the hardest part of
 implementing this will be figuring out what config needs tweaking to
 allow that.

I think that credential delegation is configured at the domain
controller and client side, as this nice article describes:
http://spnego.sourceforge.net/credential_delegation.html

 I am sure this would be useful for some applications - for example the
 one that we are currently developing needs functionality like this.

 Testing help always appreciated if you are happy running the latest
 7.0.x release (this should be in 7.0.12 which I plan to start releasing
 just as soon as I finish everything on my todo list).


We already have some hand written custom code for this. We will not be
switching to 7.0.x (we will be deploying to tcServer in producion, and
it will probably take lots of time for 7.0.12 changes to appear in
some version of tcServer, so we need the custom code we have at the
moment).
I might however try to deploy our app to 7.0.12 when it is out - and
see how much of our custom code will get removed by this spnego
support that you are writing now.

-- 
Why?
Because YES!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-29 Thread Mark Thomas
On 29/03/2011 21:18, Borut Hadžialić wrote:
 On Tue, Mar 29, 2011 at 9:57 PM, Mark Thomas ma...@apache.org wrote:
 It is in scope with the caveat - as always - that it depends on what the
 final implementation looks like. I do know (from debug logging) that
 right now tokens do not allow delegation. I suspect the hardest part of
 implementing this will be figuring out what config needs tweaking to
 allow that.
 
 I think that credential delegation is configured at the domain
 controller and client side, as this nice article describes:
 http://spnego.sourceforge.net/credential_delegation.html

Thanks. That is one of the many articles I have read over the last few
days but I had forgotten which ones mentioned what. I'll take a look.

 I am sure this would be useful for some applications - for example the
 one that we are currently developing needs functionality like this.

 Testing help always appreciated if you are happy running the latest
 7.0.x release (this should be in 7.0.12 which I plan to start releasing
 just as soon as I finish everything on my todo list).

 
 We already have some hand written custom code for this. We will not be
 switching to 7.0.x (we will be deploying to tcServer in producion, and
 it will probably take lots of time for 7.0.12 changes to appear in
 some version of tcServer, so we need the custom code we have at the
 moment).

Fair enough.

off-topic
With my VMware hat on that is is probably going to be sooner than you
think it is but I can't give you any firm dates.
/off-topic

 I might however try to deploy our app to 7.0.12 when it is out - and
 see how much of our custom code will get removed by this spnego
 support that you are writing now.

That would be great. Any testing and feedback is always helpful.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-28 Thread Borut Hadžialić
Hellos Stefan,

if you can't fix your problem with configuration and decide that you
want to solve the problem by programming, then this might help you
http://blog.springsource.com/2009/09/28/spring-security-kerberos/
After understanding that article a developer should be able to add a
SPNEGO implementation (probably not the whole protocol, just as much
it is needed for your app) to your Tomcat application by adding some
filters.
What the implementation needs to do is basically:
 1. If there is a 'Negotiate ..' http header or other authentication,
read it and process it.

 2. Otherwise if there is no authentication, send a spnego challenge
//HttpServletResponse response
response.addHeader(WWW-Authenticate, Negotiate);
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
response.flushBuffer();


On Sun, Mar 27, 2011 at 8:26 PM, Stefan Mayr ste...@mayr-stefan.de wrote:
 Hello everybody,

 as many others before we wanted to do single-sign-on for intranet web
 applications using integrated windows authentication (negotiate because IE
 sometimes tries NTLM instead of using plain kerberos - breaking all our
 kerberos-only experiments).

 We thought that IIS would be the best choice for integrated windows
 authentication and we could pass the user via AJP (using mod_jk) to our
 tomcat instances.

 Our setup:
 - Windows 2008 R2 using IIS 7.5 (64bit)
 - mod_jk 1.2.31
 - Oracle Java 1.6 U24
 - Tomcat 6.0.32

 At first glance using tomcatAuthentication=false worked as expected. We got
 the remote user and started deploying an application. End of happiness - the
 application complained about a missing user-agent. That header was not
 passed to tomcat when authentication was enabled on IIS.

 Some research revealed Bug 47679 - Not all headers get passed to Tomcat
 server from isapi_redirect.dll
 (https://issues.apache.org/bugzilla/show_bug.cgi?id=47679)

 Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator /
 integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318).
 The last comment links a new Windows Authentication How-To from Mark Thomas.
 Looks like we have already tried almost all proposed solutions:

 - IIS + mod_jk:
  tried but stuck in Bug 47679. Also tried ARR to pass the user name
  as a request header from IIS to Tomcat without success
 - Apache mod_ntlm: used it and we replaced it by the much more stable
  mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default)
 - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit
  plattform - we couldn't get stability problems solved on Apache 2.2
  and 64bit Linux. No ongoing development.
 - Apache mod_auth_sspi: till now in internal use for a very small
  project (works just fine), not sure about the future. Although
  there seems to be some new activity on 1.0.5 beta
 - Waffle: found it on thursday and it is on my our todo-list for
  testing it next week

 Any chances to get Bug 47679 solved? How can we help (we are admins, no
 devs)?
 What solutions have you deployed? Recommendations?

 Thank you,

        Stefan Mayr

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org





-- 
Why?
Because YES!

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-28 Thread Mark Thomas
On 28/03/2011 08:42, Borut Hadžialić wrote:
 Hellos Stefan,
 
 if you can't fix your problem with configuration and decide that you
 want to solve the problem by programming, then this might help you
 http://blog.springsource.com/2009/09/28/spring-security-kerberos/
 After understanding that article a developer should be able to add a
 SPNEGO implementation (probably not the whole protocol, just as much
 it is needed for your app) to your Tomcat application by adding some
 filters.

Or you could just add Spring Security to your app. I'll add that as an
option to the new How-To.

 Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator /
 integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318).
 The last comment links a new Windows Authentication How-To from Mark Thomas.
 Looks like we have already tried almost all proposed solutions:

Thanks for the great feedback on the options. I put the existing how-to
together pretty much entirely on some Google searches. I'll add your
feedback to the how-to / maybe remove some options that don't look viable.

 - IIS + mod_jk:
  tried but stuck in Bug 47679. Also tried ARR to pass the user name
  as a request header from IIS to Tomcat without success
 - Apache mod_ntlm: used it and we replaced it by the much more stable
  mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default)
 - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit
  plattform - we couldn't get stability problems solved on Apache 2.2
  and 64bit Linux. No ongoing development.
 - Apache mod_auth_sspi: till now in internal use for a very small
  project (works just fine), not sure about the future. Although
  there seems to be some new activity on 1.0.5 beta
 - Waffle: found it on thursday and it is on my our todo-list for
  testing it next week

 Any chances to get Bug 47679 solved? How can we help (we are admins, no
 devs)?
 What solutions have you deployed? Recommendations?

It is tricky to recommend something right now. I'm guessing you want
something that a) works reliably and b) is likely to be supported for
the long term. Right now Waffle probably comes closest to that. It you
can wait a little while, I should have SPNEGO support in Tomcat 7 fairly
soon. It may - or may not - get back-ported to Tomcat 6. It will depend
on the eventual solution.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Windows Authentication: Issue 49318 vs 47679

2011-03-28 Thread spring
 I should have SPNEGO support in Tomcat 7 fairly soon. 

This would be great!


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication: Issue 49318 vs 47679

2011-03-28 Thread Stefan Mayr

Hi Mark,

Am 28.03.2011 10:49, schrieb Mark Thomas:

On 28/03/2011 08:42, Borut Hadžialić wrote:

Hellos Stefan,

if you can't fix your problem with configuration and decide that you
want to solve the problem by programming, then this might help you
http://blog.springsource.com/2009/09/28/spring-security-kerberos/
After understanding that article a developer should be able to add a
SPNEGO implementation (probably not the whole protocol, just as much
it is needed for your app) to your Tomcat application by adding some
filters.


Or you could just add Spring Security to your app. I'll add that as an
option to the new How-To.


I guess this is the classic kerberos/keytab approach (no NTLM-fallback) 
that many solutions offer.



Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator /
integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318).
The last comment links a new Windows Authentication How-To from Mark Thomas.
Looks like we have already tried almost all proposed solutions:


Thanks for the great feedback on the options. I put the existing how-to
together pretty much entirely on some Google searches. I'll add your
feedback to the how-to / maybe remove some options that don't look viable.


- IIS + mod_jk:
  tried but stuck in Bug 47679. Also tried ARR to pass the user name
  as a request header from IIS to Tomcat without success
- Apache mod_ntlm: used it and we replaced it by the much more stable
  mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default)
- Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit
  plattform - we couldn't get stability problems solved on Apache 2.2
  and 64bit Linux. No ongoing development.
- Apache mod_auth_sspi: till now in internal use for a very small
  project (works just fine), not sure about the future. Although
  there seems to be some new activity on 1.0.5 beta
- Waffle: found it on thursday and it is on my our todo-list for
  testing it next week

Any chances to get Bug 47679 solved? How can we help (we are admins, no
devs)?
What solutions have you deployed? Recommendations?


It is tricky to recommend something right now. I'm guessing you want
something that a) works reliably and b) is likely to be supported for
the long term. Right now Waffle probably comes closest to that. It you
can wait a little while, I should have SPNEGO support in Tomcat 7 fairly
soon. It may - or may not - get back-ported to Tomcat 6. It will depend
on the eventual solution.


You're definitely right. We search for the holy grail of intranet 
authentication. a+b is a must.


The idea of using IIS with ARR in reverse proxy mode passing a username 
was dead end: Microsoft pointed us to a nice article describing HTTP 
request processing order. Rewriting a request comes before the 
authentication modul - so nothing to append to a header or request in 
the first place.
See 
http://learn.iis.net/page.aspx/501/iis-70-request-filtering-and-url-rewriting/

Leaves IIS with mod_jk if you can live with Bug 47679.

Our first test with Waffle is promising. Now it needs to be integrated 
and in our application for further testing.


Native SPNEGO in Tomcat sounds great. Waiting a little while depends on 
your scale of little. Is there already some development we can follow? 
Will this use Java GSS? I never figured out how to configure this with 
Tomcat.


   Stefan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Windows Authentication against multiple domains

2007-02-11 Thread Pulkit Singhal

I can't suggest any open-source/free products but allow me to suggest
reading the following article if you want to roll your own solution one of
these days in the windows world:
http://www.microsoft.com/msj/0899/kerberos/kerberos.aspx

Once you read it, I hope you will be able to see how you can put some amount
of work in from your side and leverage Kerberos as a solution across Windows
domains.

But may be I misunderstood your problem, may be you don't want SSO across
multiple domains. Maybe you simply want a piece of code that can connect to
multiple ADs instead of just one? I suggest a bit more clarification so that
the list readers may understand your use-case.

Cheers!

On 2/9/07, Suneet Shah [EMAIL PROTECTED] wrote:


Hello,
We have this capability in our open source identity and access management
solution where you can use more then one use more then one repository for
authentication. You may be able to use just the authentication service as
taking on the rest of it may be more then what you need.  The project is
OpenIAM on sourceforge. We will be putting a new release this weekend. If
you are interested in taking a look, let me know and I can send you a
link.

Regards
Suneet



On 2/9/07, Uwe_77 [EMAIL PROTECTED] wrote:


 Sure, I will let you know. Perhaps we need third party tools. Doese
 someone
 knows a solution?
 --
 View this message in context:

http://www.nabble.com/RE%3A-Windows-Authentication-against-multiple-domains-tf3203321.html#a8895171
 Sent from the Tomcat - User mailing list archive at Nabble.com.


 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





RE: Windows Authentication against multiple domains

2007-02-09 Thread Propes, Barry L [GCG-NAOT]
if you find out, please let me know...I'm barking up that tree, too.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, February 09, 2007 4:50 PM
To: users@tomcat.apache.org
Subject: Windows Authentication against multiple domains


Hi,
 
I am having a tomcat webapplication and logon needs to be done via
windows-authentication (ldap). I configured authentication against ldap,
that works fine for one domain. The problem is, that we are having users in
multiple domains. Is there a way to configure authentication against the
whole active directory forest?
 
Thanks for your help!
 
Uwe
 

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Windows Authentication against multiple domains

2007-02-09 Thread Uwe_77

Sure, I will let you know. Perhaps we need third party tools. Doese someone
knows a solution?
-- 
View this message in context: 
http://www.nabble.com/RE%3A-Windows-Authentication-against-multiple-domains-tf3203321.html#a8895171
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Windows Authentication against multiple domains

2007-02-09 Thread Suneet Shah

Hello,
We have this capability in our open source identity and access management
solution where you can use more then one use more then one repository for
authentication. You may be able to use just the authentication service as
taking on the rest of it may be more then what you need.  The project is
OpenIAM on sourceforge. We will be putting a new release this weekend. If
you are interested in taking a look, let me know and I can send you a link.

Regards
Suneet



On 2/9/07, Uwe_77 [EMAIL PROTECTED] wrote:



Sure, I will let you know. Perhaps we need third party tools. Doese
someone
knows a solution?
--
View this message in context:
http://www.nabble.com/RE%3A-Windows-Authentication-against-multiple-domains-tf3203321.html#a8895171
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: Windows Authentication against multiple domains

2007-02-09 Thread John Najarian
I am yet another barking up that tree.
--- Propes, Barry L [GCG-NAOT]
[EMAIL PROTECTED] wrote:

 if you find out, please let me know...I'm barking up
 that tree, too.
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Friday, February 09, 2007 4:50 PM
 To: users@tomcat.apache.org
 Subject: Windows Authentication against multiple
 domains
 
 
 Hi,
  
 I am having a tomcat webapplication and logon needs
 to be done via
 windows-authentication (ldap). I configured
 authentication against ldap,
 that works fine for one domain. The problem is, that
 we are having users in
 multiple domains. Is there a way to configure
 authentication against the
 whole active directory forest?
  
 Thanks for your help!
  
 Uwe
  
 

-
 To start a new topic, e-mail:
 users@tomcat.apache.org
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 



 

Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]