Name |
Windows Integrated Authentication for Crowd-enabled Applications |
---|---|
Version |
1.0 |
Product Versions |
Crowd 1.5.2 |
Author(s) |
Bruno Vincent |
Homepage |
|
Price |
Free |
License |
|
JavaDocs |
|
IssueTracking |
|
Download |
|
Download Source |
Description/Features
Automatic Logon to Crowd-enabled Applications in a Windows Domain.Windows Integrated Authentication (or Integrated Windows Authentication) allows Windows domain users to log into web applications without providing an application password. This functionality can be provided through Kerberos or NTLM.
The plugin provided here implements Windows Integrated Authentication for Crowd-enabled applications (e.g.: your own applications, Atlassian Confluence, Jira, Crowd's administration console, etc.).
The latest version implements both NTLM and Kerberos.
Prerequisites
The plugin has been tested with Crowd Server 1.5.2 in a "full Windows" environment:
- Active Directory 2003
- Tomcat v5.5, v6 (Windows 2003)
- WebSphere Application Server v6.1.0.13 (NTLM version only, Windows 2003)
- MS Internet Explorer v6, v7 (Win XP, 2003)
- Mozilla Firefox v2, v3 (Win XP, 2003)
Other versions (Linux, GlassFish, Opera etc.) might work as well. Please let me know about successful deployments.
Please note that Java 6 and Windows 2003 SP1 are required to run the Kerberos implementation.
Usage
The Windows Integrated Authentication plugin is a simple servlet filter. It first checks wether the user owns a valid Crowd token or not. If not, it sends a Kerberos or NTLM challenge to the user. If the challenge succeeds, it creates a Crowd token for that user.
The target application must be linked (through Crowd's Administration Console) to a directory (Internal, LDAP etc.) that contains the same userid as the one used to logon to the Windows workstation. That userid (the one in Crowd's directory) should be either in lower case (e.g.: bruno) or upper case (e.g.: BRUNO) format, but not in a mix of them (e.g. Bruno). The format of the Windows username does not matter.
Set up Windows Integrated Authentication
First of all, install and configure Crowd SSO for your application (see Atlassian Documentation).
Then, choose either NTLM or Kerberos as an authentication method and follow the corresponding steps.
Set up NTLM Authentication
Install and Configure the servlet filter
- Download the latest WindowsIntegratedAuth_X.X.jar, jcifs-1.2.24.jar and log4j.properties from the attachments of this page
- Copy those files to the WEB-INF/lib folder of your application
- Copy the log4j.properties file to the WEB-INF/classes folder of your application
- Edit WEB-INF/web.xml
Add the following lines before the other filters:
<filter> <filter-name>VerifyCrowdNtlmTokenFilter</filter-name> <filter-class>com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter</filter-class> <init-param> <param-name>jcifs.http.domainController</param-name> <param-value>Domain_Controller_FQDN</param-value> </init-param> <init-param> <param-name>jcifs.smb.client.domain</param-name> <param-value>Windows_Domain_Name</param-value> </init-param> <init-param> <param-name>jcifs.resolveOrder</param-name> <param-value>DNS</param-value> </init-param> <init-param> <param-name>jcifs.smb.client.username</param-name> <param-value>Windows_Account_With_Read_Rights</param-value> </init-param> <init-param> <param-name>jcifs.smb.client.password</param-name> <param-value>Windows_Account_Password</param-value> </init-param> </filter>
jCIFS parameters are fully detailed on jCIFS's website.
Please, note that if you use jcifs-1.3.0.jar or above (that you might have downloaded from jCIFS's website), you need to add the following parameter to the latter configuration:
<init-param> <param-name>jcifs.smb.client.useExtendedSecurity</param-name> <param-value>false</param-value> </init-param>
Then, add the following lines before the other filter mappings:
<filter-mapping> <filter-name>VerifyCrowdNtlmTokenFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
The url-pattern should be the same as the one used by VerifyTokenFilter (which is provided by Atlassian). Please note that you do not need VerifyTokenFilter anymore since the Windows Integrated Authentication filter checks wether the user owns a valid Crowd token before trying an NTLM challenge. However, you might keep it for simpler integration. This would only mean that users' tokens would be validated twice.
Configure Internet Explorer and Mozilla Firefox
In Internet Explorer, go to Tools > Internet Options > Local intranet > Sites > Advanced and add your intranet, e.g.: http://*.itekia.com
IE6/7 users also need to add a value to the following registry key: HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Internet Settings/
Value Name: DisableNTLMPreAuthData Type: REG_DWORDValue: 1
In Firefox, type about:config in the address bar.
Then edit network.automatic-ntlm-auth.trusted-uris and add your intranet, e.g.: .itekia.com
Test NTLM Authentication
Restart your application and open its home page using Firefox or Internet Explorer, e.g. http://confluence.itekia.com:8080/ or http://crowd.itekia.com:8095/crowd/
You should be logged on automatically. If not, verify that your browser is enabled for NTLM authentication (otherwise you will see an authentication popup window) and that the userid in the directory that is linked to the application is the same as the one you used to logon to your Windows Workstation.
Set up Kerberos Authentication
Configure Kerberos in Active Directory
- Download and install the Windows Support tools from this link.
- Create a regular Windows user in Active Directory. Let's call him crowd.
- Type the following line in a command prompt. This will map crowd to a Kerberos Service Principal Name (SPN):
ktpass -out appsrv.keytab -princ HTTP/Fqdn_Of_Your_Application_Server@YOUR_WINDOWS_DOMAIN -mapuser crowd -pass Crowd_User_Password -ptype KRB5_NT_PRINCIPAL
For instance:
ktpass -out appsrv.keytab -princ HTTP/my.appserver.itekia.com@ITEKIA.COM -mapuser crowd -pass password -ptype KRB5_NT_PRINCIPAL
Configure Kerberos in your application server
- Copy appsrv.keytab from Active Directory to your application server
- Edit C:\Kerberos\jaas-krb5.conf
com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required storeKey=true keyTab="c:\\Kerberos\\appsrv.keytab" doNotPrompt=true useKeyTab=true realm="YOUR_WINDOWS_DOMAIN" principal="HTTP/Fqdn_Of_Your_Application_Server" debug=true; };
For instance:
com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required storeKey=true keyTab="c:\\Kerberos\\appsrv.keytab" doNotPrompt=true useKeyTab=true realm="ITEKIA.COM" principal="HTTP/my.appserver.itekia.com@ITEKIA.COM" debug=true; };
Then edit C:\Kerberos\krb5.conf
[libdefaults] default_realm = YOUR_WINDOWS_DOMAIN default_tkt_enctypes = des-cbc-md5 rc4-hmac default_tgs_enctypes = des-cbc-md5 rc4-hmac [realms] YOUR_WINDOWS_DOMAIN = { kdc = Fqdn_Of_Your_Active_Directory_Server:88 default_domain = .your_windows_domain_extension } [domain_realm] .your_windows_domain_extension = YOUR_WINDOWS_DOMAIN
For instance:
[libdefaults] default_realm = ITEKIA.COM default_tkt_enctypes = des-cbc-md5 rc4-hmac default_tgs_enctypes = des-cbc-md5 rc4-hmac [realms] ITEKIA.COM = { kdc = itekia-win2003.itekia.com:88 default_domain = .itekia.com } [domain_realm] .itekia.com = ITEKIA.COM
Then add the following Java options to the startup script of your application server (e.g.: you might do this in setenv.bat for a Tomcat application server):
-Djava.security.auth.login.config=C:\Kerberos\jaas-krb5.conf -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.krb5.conf=C:\Kerberos\krb5.conf
Install and Configure the servlet filter
- Download the latest WindowsIntegratedAuth_X.X.jar and log4j.properties from the attachments of this page
- Copy WindowsIntegratedAuth_X.X.jar to the WEB-INF/lib folder of your application
- Copy the log4j.properties file to the WEB-INF/classes folder of your application
- Edit WEB-INF/web.xml
Add the following lines before the other filters:
<filter> <filter-name>VerifyCrowdKerberosTokenFilter</filter-name> <filter-class>com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter</filter-class> <init-param> <param-name>kerberos.application.principal</param-name> <param-value>HTTP/Fqdn_Of_Your_Application_Server</param-value> </init-param> </filter>
Then, add the following lines before the other filter mappings:
<filter-mapping> <filter-name>VerifyCrowdKerberosTokenFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
The url-pattern should be the same as the one used by VerifyTokenFilter (which is provided by Atlassian). Please note that you do not need VerifyTokenFilter anymore since the Windows Integrated Authentication filter checks wether the user owns a valid Crowd token before trying a Kerberos challenge. However, you might keep it for simpler integration. This would only mean that users' tokens would be validated twice.
Configure Internet Explorer and Mozilla Firefox
In Internet Explorer, go to Tools > Internet Options > Local intranet > Sites > AdvancedAnd add your intranet, e.g.: http://*.itekia.com
In Firefox, type about:config in the address bar.
Then edit network.negotiate-auth.trusted-uris and add your intranet, e.g.: .itekia.com
Test Kerberos Authentication
Restart your application and open its home page using Firefox or Internet Explorer, e.g. http://confluence.itekia.com:8080/ or http://crowd.itekia.com:8095/crowd/
You should be logged on automatically. If not, verify that your browser is enabled for Kerberos authentication (otherwise you will see the usual application login form) and that the userid in the directory that is linked to the application is the same as the one you used to logon to your Windows Workstation.
Version History
Version |
Release Date |
Description |
---|---|---|
0.9 |
November 24th, 2008 |
Initial Version |
1.0 |
December 26th, 2008 |
Kerberos Support |
Limitations
The Kerberos implementation relies on Java 6. If your application server runs on an earlier version of Sun's JRE, you should consider using NTLM instead.
43 Comments
Nicholas Muldoon [Atlassian]
Extremely cool Bruno!
S
Crowd has long needed this feature - so I'm really glad to see this plugin. However... There's no apparent way of turning on NTLM authentication for all but the remote API (using its trusted application authentication). As currently enabling this plugin for Fisheye/Crucible prevents the Jira Fisheye plugin from communicating with it.
John Baker
Hi,
Have you made any progress with Kerberos? Is there anywhere I can view (and perhaps contribute) to work so far?
John
Bruno Vincent
Hi John,
time is actually flying! I wanted to do this earlier but I have not had much free time recently. I had found a few SPNEGO code implementation examples on the web so as far as I understood them, this should not be too complex to implement. I will try to do code the rest of this plugin asap. In the meantime, please feel free to email me so that I can give you the hints I have found so far.
Bruno
Bruno Vincent
Hi John,
Well, I have good news: the Kerberos version is now ready for use!
It works well on Tomcat and should also be ok for any Java 6 application server.
Bruno
Nicholas Muldoon [Atlassian]
Very cool Bruno!
Coen Hyde
No luck with a linux install. This is a feature that we're dieing to have. It will definatly help our adoption of confluence (most/all users just don't log in, even though it's their homepage)
Bruno Vincent
Hi Coen,
Did you try the NTLM or Kerberos implementation ? I would not be surprised that the Kerberos version needs to be adapted to work on a Linux box. However the NTLM implementation should immediately run since the jCIFS library is supported on both operating systems. What do you get in the log files ?
Bruno
Coen Hyde
Hi Bruno,
I was trying to implement NTLM. When i set it up as discribed above i get an ArrayIndexOutOfBoundsException thrown when i try to access it in the web browser. It seems to startup fine.
I've uploaded the output here http://www.2shared.com/file/4629021/4b07b6d7/exception.html
Cheers,
Coen
Bruno Vincent
Hi Coen,
I remember I had this very exception on Windows when I was developing the NTLM plugin. The reason why was the version of the jCIFS library (the ByteToArray method which throwns the exception is part of it). Version 1.3 used to throw the exception whereas version 1.2.24 did not. That is why I included version 1.2.24 in the attachments of this page.
Which version did you use ?
Bruno
Andy Brook [Plugin People]
Hi guys, it should be possible to use 1.3.x, I stumbled across the issue on the Confluence NTLM authenticator. The exception is probably coming from the response processing, whereby jcifs is returning a 0byte rather than 8byte NTLM response. Set the following environement variable on jcifs and it should work fine:
Andy
Bruno Vincent
Hi Andy,
your tip just works fine! I have added it to the documentation.
Thanks a lot.
Bruno
Coen Hyde
Ah.. yes i was using version 1.3.x. Andy's solution worked at treat. But due to the problem below i reverted to 1.2.24 just in case.
Now that i've enabled this filter confluence redirects to localhost:8080...(jira), obviously the user doesn't have jira installed on their local machine, so that's bad news..also why jira?. We use apache as a proxy to route confluence.server to server:8081 and jira.server to server:8080. If i load up server:8081 or server:8080 i get confluence and jira respectivly all logged in and ready to go. NTLM is working.
Coen
Bruno Vincent
Hi Coen,
Hmm, there's absolutely no hard coded URL in the filter so I guess you probably need to modify the crowd.properties file of your application. That's what I meant in the documentation with "First of all, install and configure Crowd SSO for your application "
You should also be careful with Crowd token's domain. If Crowd has been configured for the ".server" domain, the cookie will not be sent to URL that do not include this domain.
Bruno
Coen Hyde
Hi Bruno,
Thanks for your help. SSO for confluence and jira was working fine before i attempted to set up this filter and still is if i request confluence through it's port number (NTLM works as well). In the crowd.properties file there is a setting 'application.login.url' which was set to http://localhost:8080/. It appears as though the plugin is not authenticating when i request confluence through the reverse proxy (confluence.server) as opposed to server:8081 (if i remove the filter mapping everything works... well except for NTLM.. ). I have tried changing 'application.login.url' to all kinds of variations of confluence, except i get an infinate redirect loop. Any idea on what is going wrong?
Cheers,
Coen
EDIT: After some research if may not be possible for apache to pass through NTLM.
Bruno Vincent
Hi Coen,
I should have seen what was going wrong at first sight, sorry about that! You are right, the reason why is actually the reverse proxy mode which disables NTLM. Thus, your requests are not authenticated and the plugin redirects you to the login page which is configured to be http://localhost:8080 in the crowd.properties file.
I am not sure there is a solution to pass through NTLM in an Apache Reverse Proxy. You might want to try this: http://modntlm.sourceforge.net/ (they say there is patch that supports reverse proxy mode).
Bruno
Andy Brook [Plugin People]
Bleugh, use mod_jk, job done
Coen Hyde
Yeah that's what i was going to try first.
masuman
Hi All,
Is there any way i can specify in the url-patten tag of VerifyCrowdNtlmTokenFilter
to skip authentication for a specific action like "login.action".
We want to have a fall back mechanism where non domain people should be redirected to a login form. Currently a blank screen appears when the user is
redirected to the login page specified in crowd.properties file (which i guess is due to the use of /*).
Our applcation is running in linux environment and the silent login works perfectly for domain users with NTLM authentication.
Kind Regards,
M.A.Suman.
Bruno Vincent
Hi Suman,
you can actually apply the filter to something else than "/*". For example you could apply the filter to "/secure/*", which would be the private part of your application, and not apply it to "/login.jsp".
You can also modify the filter very easily. In the doFilter method of VerifyCrowdNtlmTokenFilter, you just need to chain the filter before any other action if the requested URL equals the value of formLoginPage.
Hope this helps.
Bruno
masuman
Hi Bruno,
Thanks for the reply. I am able to skip authentication for login.action by following the above steps, but i have run into a different problem.
Actually we want the fallback to login form to happen when NTLM authentication fails.
Currently non domain users are prompted with a login box to provide credentials. If they press cancel then nothing is happening. Looks like this cancel request
is not being propagated back to the application and the user is shown a blank screen. (is it because the authentication code is being called from a filter instead of a servlet ?)
Also for some reason response.sendRedirect is not working.
Can you please provide me a different approach for this.
Kind Regards,
M.A.Suman
Coen Hyde
This is similar in functionality to what i'd like. We have a few users who anonymously browse our wiki as they do not have accounts. It's impractical to give them accounts as they are only browsing for one session and they will never be back. It would be nice if we had the option of falling back to standard authentication. Preferred behavior would be if NTLM succeeds then fantastic, if it doesn't then behave as usual pre NTLM filter.
masuman
Hi All,
Finally found a work around.
Initially i thought of adopting an IP based approach to distinguish between domain and external users, but as our proxy server was coming in between so it was not possible to get the remote users ip address. (This approach may be valid and useful for others)
2nd was to use a certificate based approach . All users in our domain have a special certificate identifying them as employees in the browser. So i did the following changes.
a) Edit the attribute clientAuth="false" to clientAuth="want" in connector tag of tomcat's server.xml file. This attribute makes the browser submit all the user certificates to the application.
b) In the do filter method get all the certificates using
X509Certificate[] certs = (java.security.cert.X509Certificate[])request. getAttribute( "javax.servlet.request.X509Certificate" );
c) Check each X509Certificate object to see if the Issuer Dn string matches that of your company.
(For example) certs[0].getIssuerDn().getName().equals("[YOUR_COMPANY_DN]")
If no matching certificate is found then the user can be considered an external user and can be directly forwarded to the login page if he does not have a valid crowd token.
Kind Regards,
M.A.Suman.
Bruno Vincent
Hi guys,
sorry for replying so late.
Well, first of all, I am glad you found a solution. You actually needed to find a way to distinguish between the domain users and the external users before applying the NTLM filter (and you are right, the proxy's IP address might be in most cases a very good criteria).
The reason why we cannot do that once the NTLM process has begun is because the browser opens an authentication pop-up window when it receives the "WWW-Authenticate: NTLM" header which is the very first step of the NTLM process (of course, the browser opens the pop-up window only if it cannot send a correct answer to this "challenge"). If you click "cancel" you actually get a blank screen because the browser does not do anything else afterwards (there is no other HTTP request sent to the server).
I guess there might be a solution for the Kerberos implementation with Ajax (see Taglabs' implementation: Try Spnego Login with JavaScript on http://dev.taglab.com/sites/taglab-public/support/spnego.html).
Regards,
Bruno
masuman
Hi Bruno,
When ever NTLM authentication succeds i am not able to edit or create anything in wiki using I.E .
While saving every time i get validation errors from server side asking to enter all the required fields even though i filled everything correctly.
This problem does not come in firefox. Upon further debugging i see that none of the request parameters are received. This only happens when NTLM authentication succeeds.
Did any one else face this problem. Why arent request parameters received when NTLM authentication succeeds.
Also i tried rearranging the <filter-mapping> of NTLM at several places to see if it fixes the problem, but it didnt help.
Kind Regards,
M.A.Suman
Bruno Vincent
Hi,
Well, this really sounds weird. The filter does not do anything once the user has obtained a valid crowd token. Besides, even at first authentication when it "transforms" the NTLM token into the crowd token, it does not change any request parameter...
What is your wiki application ? Confluence ? Which version of Internet Explorer are you using ?
Regards,
Bruno
masuman
Hi Bruno,
I am using confluence 2.9.2. This problem occurs with both IE6 and IE7.
This seems to be a bug with IE and NTLM as i am losing most of the request data.
Further debugging is needed to find out where the problem lies.
Kind Regards,
M.A.Suman.
Bruno Vincent
Hi,
Well, sorry for the delay. I finally found time to have a look at this problem!
It is entirely due to an Internet Explorer's performance "feature". Once an IE user has logged on a web site using NTLM, IE thinks it will need to renegociate all further requests to this web site. Thus, it does not supply the POST data and prepares itself to renegociate again. This behaviour is controlled by a registry key called DisableNTLMPreAuth. Thus you need to add this key as explained in the "Configure Internet Explorer for NTLM" part of this page. I have just tested it, it does work
You might also fall back to the Kerberos implementation which is not affected by this so called IE "feature"
Regards,
Bruno
masuman
Hi Bruno,
Thanks for the information.
I switched to kerberos implementation and faced no problems.
Kind Regards,
M.A.Suman.
Mourouganandame
Hi,
I tried the plug-in and facing the following error:
System Error
A system error has occurred.
If this problem persists - please notify your JIRA administrator of this problem.
Otherwise, please create a support issue on our support system at http://support.atlassian.com with the following information:
a description of your problem
cut & paste the error and system information found below
attach the application server log file ( C:\WINDOWS\system32\atlassian-jira.log )
Cause:
GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
Stack Trace: [hide]
GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:80)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:287)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.getToken(VerifyCrowdKerberosTokenFilter.java:278)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.doFilter(VerifyCrowdKerberosTokenFilter.java:103)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
Referer URL: Unknown
Build Information:
Uptime : N/A
Edition : Enterprise
Version : 3.13.2
Build Number : 335
Atlassian Partner : null
Installation Type : Standalone
Server ID : Contact your Administrator to discover this property value.
Server Information:
Application Server: Apache Tomcat/5.5.26
Servlet Version: 2.4
File Paths:
Contact your System Administrator to discover file path information.
Memory Information:
Total Memory: 493 MB
Free Memory: 464 MB
Used Memory: 29 MB
Total PermGen Memory: 176 MB
Free PermGen Memory: 145 MB
Used PermGen Memory: 30 MB
System Information:
System Date : Thursday, 26 Mar 2009
System Time : 10:31:16
Current Working Directory : Contact your System Administrator to discover this property value.
Java Version : 1.6.0_03
Java Vendor : Sun Microsystems Inc.
JVM Version : 1.0
JVM Vendor : Sun Microsystems Inc.
JVM Implementation Version : 1.6.0_03-b05
Java Runtime : Java(TM) SE Runtime Environment
Java VM : Java HotSpot(TM) Server VM
User Name : SYSTEM
User Timezone : Asia/Singapore
User Locale : English (United States)
System Encoding : Cp1252
Operating System : Windows XP 5.1
OS Architecture : x86
Application Server Container :
Database type : hsql
Database JNDI address : java:comp/env/jdbc/JiraDS
Database URL : Hidden
Database version : 1.8.0
Database driver : HSQL Database Engine Driver 1.8.0
External user management : OFF
Crowd integration : ON
JVM Input Arguments : Contact your System Administrator to discover this property value.
Language Info:
Installed languages: Chinese (China)
Chinese (Taiwan)
Czech (Czech Republic)
Danish (Denmark)
Dutch (Belgium)
English (UK)
French (France)
German (Germany)
German (Switzerland)
Hungarian (Hungary)
Italian (Italy)
Japanese (Japan)
Norwegian (Norway)
Polish (Poland)
Portuguese (Brazil)
Russian (Russia)
Slovak (Slovakia)
Spanish (Spain)
Turkish (Turkey)
Default language: English (United States) - System Default
Request Information:
- Request URL: http://mourougana/500page.jsp
- Scheme: http
- Server: mourougana
- Port: 80
- URI: /500page.jsp
- Context Path:
- - Servlet Path: /500page.jsp
- - Path Info: null
- - Query String:
Request Attributes
- javax.servlet.forward.request_uri : /
- javax.servlet.forward.context_path :
- javax.servlet.forward.servlet_path : /default.jsp
- javax.servlet.forward.path_info : /500page.jsp
- javax.servlet.error.message :
- webwork.result : Value stack =========== ===========
- javax.servlet.error.status_code : 500
- javax.servlet.error.servlet_name : jsp
- javax.servlet.error.exception : javax.servlet.ServletException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
- javax.servlet.error.request_uri : /
Request Logging
0 log statements generated by this request:
Listeners
- Issue Cache Listener (com.atlassian.jira.event.listeners.cache.IssueCacheListener)
- Issue Index Listener (com.atlassian.jira.event.listeners.search.IssueIndexListener)
- Mail Listener (com.atlassian.jira.event.listeners.mail.MailListener)
Services
- Backup Service (com.atlassian.jira.service.services.export.ExportService)
- Delay: 720 minutes
- Mail Queue Service (com.atlassian.jira.service.services.mail.MailQueueService)
- Delay: 1 minutes
Plugins
- Admin Menu Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Browse Project Operations Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Content Link Resolvers Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Custom Field Types & Searchers 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Filter List Plugin 1.1.2 - Plugin by SourceLabs
- Enabled
- FishEye Plugin 2.2.2 - Plugin by Atlassian Software Systems
- Enabled
- Issue Operations Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Issue Tab Panels Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Issue Views Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- JIRA Bamboo Plugin 2.2 - Plugin by Atlassian Software Systems Pty Ltd
- Enabled
- JIRA Calendar Plugin 1.9 - Plugin by Atlassian Pty Ltd
- Enabled
- JIRA Charting Plugin 1.4.1 - Plugin by Atlassian Pty Ltd
- Enabled
- JIRA Footer 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Portlets Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Preset Filters Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Project Panels Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Project Role Actors Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- RPC JIRA Plugin 3.13.1 - Plugin by Atlassian Software Systems Pty Ltd
- Enabled
- Renderer Component Factories Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Renderer Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Reports Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Top Navigation Bar 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- User Format 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- User Navigation Bar Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- User Profile Links 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- View Project Operations Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Web Resources Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Webwork Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Wiki Renderer Macros Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Workflow Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
Any help is highly appreciated.
Thanks & Regards,
Mourougan
masuman
Hi Morougan,
Looks like you received a NTLM token instead of a kerberos token. Kerberos token starts with YII.... sequence
You can contact your network administrator to give you a correct keytab file and make sure that the user whose credentials will be used in
the keytab file has been mapped to the kerberos service principle.
Kind Regards,
M.A.Suman.
Mourougan
Hi Masuman,
Thanks for the response.
Now are are getting the below error. Could you able to help to guide me?
Filter: profiling] Using parameter [jira_profile]
[Filter: profiling] defaulting to off [autostart=false]
[Filter: profiling] Turning filter off [jira_profile=off]
Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is C:\JIRA-Enterprise-3.13.2\Kerberos\appsrv.keytab refreshKrb5Config is false principal is HTTP/appsupport.mda.gov.sg@MDA tryFirstPass is false useFirstPass is false storePass is false clearPass is false
principal's key obtained from the keytab
Acquire TGT using AS Exchange
2009-05-28 13:01:26,873 http-80-Processor25 WARN [itekia.crowd.integration.VerifyCrowdKerberosTokenFilter] GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)
2009-05-28 13:01:26,889 http-80-Processor25 WARN [itekia.crowd.integration.VerifyCrowdKerberosTokenFilter] GSSException major: No valid credentials provided
2009-05-28 13:01:26,889 http-80-Processor25 WARN [itekia.crowd.integration.VerifyCrowdKerberosTokenFilter] GSSException minor: Attempt to obtain new ACCEPT credentials failed!
2009-05-28 13:01:26,889 http-80-Processor25 ERROR [[Catalina].[localhost].[/].[jsp]] Servlet.service() for servlet jsp threw exception
javax.security.auth.login.LoginException: java.lang.NullPointerException
at sun.security.krb5.internal.KRBError.parsePAData(KRBError.java:216)
at sun.security.krb5.internal.KRBError.<init>(KRBError.java:193)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:53)
at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:449)
at sun.security.krb5.Credentials.sendASRequest(Credentials.java:406)
at sun.security.krb5.Credentials.acquireTGT(Credentials.java:355)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:672)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)
at javax.security.auth.login.LoginContext.login(LoginContext.java:575)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:246)
at sun.security.jgss.krb5.Krb5Util.getKeys(Krb5Util.java:185)
at sun.security.jgss.krb5.Krb5AcceptCredential$1.run(Krb5AcceptCredential.java:82)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:79)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:111)
at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:183)
at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:220)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:301)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:869)
at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:536)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.getToken(VerifyCrowdKerberosTokenFilter.java:278)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.doFilter(VerifyCrowdKerberosTokenFilter.java:103)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:872)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)
at javax.security.auth.login.LoginContext.login(LoginContext.java:575)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:246)
at sun.security.jgss.krb5.Krb5Util.getKeys(Krb5Util.java:185)
at sun.security.jgss.krb5.Krb5AcceptCredential$1.run(Krb5AcceptCredential.java:82)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:79)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:111)
at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:183)
at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:220)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:301)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:869)
at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:536)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.getToken(VerifyCrowdKerberosTokenFilter.java:278)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.doFilter(VerifyCrowdKerberosTokenFilter.java:103)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
2009-05-28 13:01:27,014 http-80-Processor25 ERROR [500ErrorPage.jsp] Exception caught in 500 page No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)
GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:87)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:111)
at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:183)
at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:220)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:301)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:869)
at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:536)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.getToken(VerifyCrowdKerberosTokenFilter.java:278)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.doFilter(VerifyCrowdKerberosTokenFilter.java:103)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.security.auth.login.LoginException: java.lang.NullPointerException
at sun.security.krb5.internal.KRBError.parsePAData(KRBError.java:216)
at sun.security.krb5.internal.KRBError.<init>(KRBError.java:193)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:53)
at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:449)
at sun.security.krb5.Credentials.sendASRequest(Credentials.java:406)
at sun.security.krb5.Credentials.acquireTGT(Credentials.java:355)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:672)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)
at javax.security.auth.login.LoginContext.login(LoginContext.java:575)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:246)
at sun.security.jgss.krb5.Krb5Util.getKeys(Krb5Util.java:185)
at sun.security.jgss.krb5.Krb5AcceptCredential$1.run(Krb5AcceptCredential.java:82)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:79)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:111)
at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:183)
at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:220)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:301)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:869)
at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:536)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.getToken(VerifyCrowdKerberosTokenFilter.java:278)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.doFilter(VerifyCrowdKerberosTokenFilter.java:103)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:872)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)
at javax.security.auth.login.LoginContext.login(LoginContext.java:575)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:246)
at sun.security.jgss.krb5.Krb5Util.getKeys(Krb5Util.java:185)
at sun.security.jgss.krb5.Krb5AcceptCredential$1.run(Krb5AcceptCredential.java:82)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:79)
... 26 more
The jass-krb5.conf file is:
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required
storeKey=true
keyTab="C:\\JIRA-Enterprise-3.13.2\\Kerberos
appsrv.keytab"
doNotPrompt=true
useKeyTab=true
realm="MDA"
principal="HTTP/appsupport.mda.gov.sg@MDA"
debug=true;
};
The krb5.conf
[libdefaults]
default_realm = MDA
default_tkt_enctypes = des-cbc-md5 rc4-hmac
default_tgs_enctypes = des-cbc-md5 rc4-hmac
[realms]
MDA =
[domain_realm]
.mda = MDA
Any clue?
Thanks in advance
Mourougan
Mathsavithri
Hi,
I tried Kerberos implementation in JIRA and get the below:
System Error
A system error has occurred.
If this problem persists - please notify your JIRA administrator of this problem.
Otherwise, please create a support issue on our support system at http://support.atlassian.com with the following information:
a description of your problem
cut & paste the error and system information found below
attach the application server log file ( C:\WINDOWS\system32\atlassian-jira.log )
Cause:
GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
Stack Trace: [hide]
GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:80)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:287)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.getToken(VerifyCrowdKerberosTokenFilter.java:278)
at com.itekia.crowd.integration.VerifyCrowdKerberosTokenFilter.doFilter(VerifyCrowdKerberosTokenFilter.java:103)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
Referer URL: Unknown
Build Information:
Uptime : N/A
Edition : Enterprise
Version : 3.13.2
Build Number : 335
Atlassian Partner : null
Installation Type : Standalone
Server ID : Contact your Administrator to discover this property value.
Server Information:
Application Server: Apache Tomcat/5.5.26
Servlet Version: 2.4
File Paths:
Contact your System Administrator to discover file path information.
Memory Information:
Total Memory: 493 MB
Free Memory: 464 MB
Used Memory: 29 MB
Total PermGen Memory: 176 MB
Free PermGen Memory: 145 MB
Used PermGen Memory: 30 MB
System Information:
System Date : Thursday, 26 Mar 2009
System Time : 10:31:16
Current Working Directory : Contact your System Administrator to discover this property value.
Java Version : 1.6.0_03
Java Vendor : Sun Microsystems Inc.
JVM Version : 1.0
JVM Vendor : Sun Microsystems Inc.
JVM Implementation Version : 1.6.0_03-b05
Java Runtime : Java(TM) SE Runtime Environment
Java VM : Java HotSpot(TM) Server VM
User Name : SYSTEM
User Timezone : Asia/Singapore
User Locale : English (United States)
System Encoding : Cp1252
Operating System : Windows XP 5.1
OS Architecture : x86
Application Server Container :
Database type : hsql
Database JNDI address : java:comp/env/jdbc/JiraDS
Database URL : Hidden
Database version : 1.8.0
Database driver : HSQL Database Engine Driver 1.8.0
External user management : OFF
Crowd integration : ON
JVM Input Arguments : Contact your System Administrator to discover this property value.
Language Info:
Installed languages: Chinese (China)
Chinese (Taiwan)
Czech (Czech Republic)
Danish (Denmark)
Dutch (Belgium)
English (UK)
French (France)
German (Germany)
German (Switzerland)
Hungarian (Hungary)
Italian (Italy)
Japanese (Japan)
Norwegian (Norway)
Polish (Poland)
Portuguese (Brazil)
Russian (Russia)
Slovak (Slovakia)
Spanish (Spain)
Turkish (Turkey)
Default language: English (United States) - System Default
Request Information:
- Request URL: http://mourougana/500page.jsp
- Scheme: http
- Server: mourougana
- Port: 80
- URI: /500page.jsp
- Context Path:
- - Servlet Path: /500page.jsp
- - Path Info: null
- - Query String:
Request Attributes
- javax.servlet.forward.request_uri : /
- javax.servlet.forward.context_path :
- javax.servlet.forward.servlet_path : /default.jsp
- javax.servlet.forward.path_info : /500page.jsp
- javax.servlet.error.message :
- webwork.result : Value stack =========== ===========
- javax.servlet.error.status_code : 500
- javax.servlet.error.servlet_name : jsp
- javax.servlet.error.exception : javax.servlet.ServletException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
- javax.servlet.error.request_uri : /
Request Logging
0 log statements generated by this request:
Listeners
- Issue Cache Listener (com.atlassian.jira.event.listeners.cache.IssueCacheListener)
- Issue Index Listener (com.atlassian.jira.event.listeners.search.IssueIndexListener)
- Mail Listener (com.atlassian.jira.event.listeners.mail.MailListener)
Services
- Backup Service (com.atlassian.jira.service.services.export.ExportService)
- Delay: 720 minutes
- Mail Queue Service (com.atlassian.jira.service.services.mail.MailQueueService)
- Delay: 1 minutes
Plugins
- Admin Menu Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Browse Project Operations Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Content Link Resolvers Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Custom Field Types & Searchers 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Filter List Plugin 1.1.2 - Plugin by SourceLabs
- Enabled
- FishEye Plugin 2.2.2 - Plugin by Atlassian Software Systems
- Enabled
- Issue Operations Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Issue Tab Panels Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Issue Views Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- JIRA Bamboo Plugin 2.2 - Plugin by Atlassian Software Systems Pty Ltd
- Enabled
- JIRA Calendar Plugin 1.9 - Plugin by Atlassian Pty Ltd
- Enabled
- JIRA Charting Plugin 1.4.1 - Plugin by Atlassian Pty Ltd
- Enabled
- JIRA Footer 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Portlets Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Preset Filters Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Project Panels Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Project Role Actors Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- RPC JIRA Plugin 3.13.1 - Plugin by Atlassian Software Systems Pty Ltd
- Enabled
- Renderer Component Factories Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Renderer Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Reports Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Top Navigation Bar 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- User Format 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- User Navigation Bar Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- User Profile Links 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- View Project Operations Sections 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Web Resources Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Webwork Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Wiki Renderer Macros Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
- Workflow Plugin 1.0 - Plugin by Atlassian Pty Ltd
- Enabled
Any help is highly appreciated.
Thanks & Regards,
Mathsavithri
veronica
Hi
I have installed "Windows Integrated Authentication for Crowd-enabled Applications" plugins for crowd but getting below error:
Cause :
java.net.UnknownHostException: Domain_Controller_FQDN
Stack Trace :
java.net.UnknownHostException: Domain_Controller_FQDN
at jcifs.UniAddress.getAllByName(UniAddress.java:315)
at jcifs.UniAddress.getByName(UniAddress.java:245)
at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.negotiate(VerifyCrowdNtlmTokenFilter.java:308)
at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.doFilter(VerifyCrowdNtlmTokenFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)
[
Build Information :
Version : 2.0.2 (Build:#409 - 06-10-2009)
Memory Information :
Total Memory : 133 MB
Free Memory : 90 MB
Used Memory : 42 MB
Request Information :
Request Attributes :
I did it with all steps provided in
Any help is highly appreciated.
Thanks & Regards,
Bruno Vincent
Hi Veronica,
You have to replace the string "Domain_Controller_FQDN" with the fully qualified domain name of your Windows controller in web.xml, for instance "mydomaincontroller.mycompany.com".
Regards,
Bruno
veronica
Hi Bruno
why this is required "WebSphere Application Server v6.1.0.13 (NTLM version only, Windows 2003)".
I dont have this is this the reason why i am getting above error. I am using Crowd Version: 2.0.2.
If it is essential let me know how and where to install it....
Thanks
Bruno Vincent
If you are using WebSphere 6, you need to have at least fixpack 13 to make the NTLM version work. You cannot use Websphere with the Kerberos version since the plugin is based on Sun's JDK, not IBM's.
But this has nothing to do with the problem you're experiencing above :-)
veronica
Bruno,
Using NTLM method , whenever credentials are provided on window popup it takes to blank page what can be the cause.
Vernoica
veronica
Bruno,
After the above problem i just replace localhost value by IP in crowd.properties so now blank screen is not coming but different error is coming see below
:
Cause :
jcifs.smb.SmbException: Connection timeout jcifs.util.transport.TransportException: Connection timeout at jcifs.util.transport.Transport.connect(Transport.java:178) at jcifs.smb.SmbTransport.connect(SmbTransport.java:293) at jcifs.smb.SmbSession.getChallenge(SmbSession.java:146) at jcifs.smb.SmbSession.getChallenge(SmbSession.java:140) at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.negotiate(VerifyCrowdNtlmTokenFilter.java:309) at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.doFilter(VerifyCrowdNtlmTokenFilter.java:149) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619)
Stack Trace : jcifs.smb.SmbException: Connection timeout
jcifs.util.transport.TransportException: Connection timeout
at jcifs.util.transport.Transport.connect(Transport.java:178)
at jcifs.smb.SmbTransport.connect(SmbTransport.java:293)
at jcifs.smb.SmbSession.getChallenge(SmbSession.java:146)
at jcifs.smb.SmbSession.getChallenge(SmbSession.java:140)
at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.negotiate(VerifyCrowdNtlmTokenFilter.java:309)
at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.doFilter(VerifyCrowdNtlmTokenFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)
at jcifs.smb.SmbTransport.connect(SmbTransport.java:295)
at jcifs.smb.SmbSession.getChallenge(SmbSession.java:146)
at jcifs.smb.SmbSession.getChallenge(SmbSession.java:140)
at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.negotiate(VerifyCrowdNtlmTokenFilter.java:309)
at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.doFilter(VerifyCrowdNtlmTokenFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)
Veronica
veronica
Bruno,
Again :) Using NTLM method , whenever credentials are provided on window popup it takes to blank page what can be the cause.
in logs such type of error is showing
2009-11-25 14:16:33,046 http-8095-2 WARN [itekia.crowd.integration.VerifyCrowdNtlmTokenFilter] Unable to connect to crowd server URL: null; nested exception is:
java.lang.NullPointerException
2009-11-25 14:17:10,437 http-8095-1 DEBUG [itekia.crowd.integration.VerifyCrowdNtlmTokenFilter] VerifyCrowdNtlmTokenFilter: vernica.grower successfully authenticated against 0.0.0.0<00>/172.16.0.114
2009-11-25 14:17:10,437 http-8095-1 FATAL [service.soap.client.SecurityServerClientImpl] Unable to connect to crowd server URL: null
Vernoica
veronica
Hi Bruno
I put crowd.properties file in classes directoy, now i jumped the above error but this error is still coming on the screen
Cause :
org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Server returned error code = 401 for URI : http://172.16.0.114:8095/crowd/services/SecurityServer. Check server logs for details
Stack Trace : org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Server returned error code = 401 for URI : http://172.16.0.114:8095/crowd/services/SecurityServer. Check server logs for details
org.codehaus.xfire.fault.XFireFault: Server returned error code = 401 for URI : http://172.16.0.114:8095/crowd/services/SecurityServer. Check server logs for details
at org.codehaus.xfire.fault.XFireFault.createFault(XFireFault.java:89)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:83)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114)
at org.codehaus.xfire.client.Client.invoke(Client.java:336)
at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
at $Proxy71.authenticateApplication(Unknown Source)
at com.atlassian.crowd.integration.service.soap.client.SecurityServerClientImpl.authenticate(SecurityServerClientImpl.java:191)
at com.atlassian.crowd.integration.service.soap.client.SecurityServerClientImpl.getApplicationToken(SecurityServerClientImpl.java:168)
at com.atlassian.crowd.integration.service.soap.client.SecurityServerClientImpl.findPrincipalByName(SecurityServerClientImpl.java:634)
at com.itekia.crowd.integration.VerifyCrowdNtlmTokenFilter.doFilter(VerifyCrowdNtlmTokenFilter.java:166)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.codehaus.xfire.XFireRuntimeException: Server returned error code = 401 for URI : http://172.16.0.114:8095/crowd/services/SecurityServer. Check server logs for details
at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:130)
at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
... 21 more
kindly suggest the solution
veronica
Bruno Vincent
You should check the application name and password in crowd.properties and check that they are the same as the ones you entered in the crowd console when registering the application...
(You should also have a look to the allowed remote addresses)
veronica
Hi Bruno
Checked both the things are correct still same error :(
org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Server returned error code = 401 for URI : http://localhost:8095/crowd/services/SecurityServer.