Policy extension w/ NTLM auth
This could be a RAM, WebSphere, or Jcifs issue.
I need to deploy a RAM Extension that encapsulates an axis2 web service client executing web service calls to SharePoint enforcing NTLMv2 with zero chance of basic / anonymous access.
The core code works 100% using a basic java client wrapper.
When wrapped in the policy extension framework, authentication fails with a 401. I did the instrumentation to make sure the configuration options done through policy extension configuration are being captured and configured correctly. We are using the eWAS bundled with RAM.
However, in doing the packet level trace, I discovered the challenge response from the web service fails and it looks like it's might even be passing it back with a different hashing algorithm?
My main issue is I don't know if any classes are bundled in ewas, or any features like TAI, are enabled that could be disrupting the NTLM auth. Further, the method by which RAM executes the Policy Extension is fairly undocumented and nebulous, so I don't know if there's any additional constraints.
Trace is the following: (C) is for the web service client running in the java wrapper and websphere, (S) is for the SharePoint server.
Client Wrapper
C: Authorization: NTLM TlRMTVNTUAABAAAABnIAAAwADAAgAAAAIgAiACwAAABBVE9UTkVUUFJEQ1RTWUQwMkkxNTJGVi5QUk9EVUNULkFUT1RORVQuR09WLkFV
S: WWWAuthenticate: NTLM TlRMTVNTUAACAAAADAAMADgAAAAGAoECBichviKMTGYAAAAAAAAAANIA0gBEAAAABQLODgAAAA9BVE9UTkVUUFJEQ1QCABgAQQBUAE8AVABOAEUAVABQAFIARABDAFQAAQAWAFMAWQBEADAAMgBJADEANQAyAEYAVgAEACwAcAByAG8AZAB1AGMAdAAuAGEAdABvAHQAbgBlAHQALgBnAG8AdgAuAGEAdQADAEQAcwB5
C: Authorization: NTLM TlRMTVNTUAADAAAAGAAYAEAAAAACAQIBWAAAAAwADABaAQAABQAFAGYBAAAiACIAawEAAAAAAAAAAAAAggIAAO6xkIlyRvP9JczedCS9DF0wqvHsaFUGO6BI34NTop6W0IwRWwdfc+kBAQAAAAAAALBs/hltnswBalIRIQE3UgEAAAAAAgAYAEEAVABPAFQATgBFAFQAUABSAEQAQwBUAAEAFgBTAFkARAAwADIASQAxAD
Result: 200
WebSphere
C: Authorization: NTLM TlRMTVNTUAABAAAABlIAAAwADABCAAAAIgAiACAAAABTWUQwMkkxNTJGVi5QUk9EVUNULkFUT1RORVQuR09WLkFVQVRPVE5FVFBSRENU
S: WWWAuthenticate: NTLM TlRMTVNTUAACAAAADAAMADgAAAAGAoECKyDWBIZvorQAAAAAAAAAANIA0gBEAAAABQLODgAAAA9BVE9UTkVUUFJEQ1QCABgAQQBUAE8AVABOAEUAVABQAFIARABDAFQAAQAWAFMAWQBEADAAMgBJADEANQAyAEYAVgAEACwAcAByAG8AZAB1AGMAdAAuAGEAdABvAHQAbgBlAHQALgBnAG8AdgAuAGEAdQADAEQAcwB5
C: Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHMAAAAAAAAAiwAAAAwADABAAAAABQAFAEwAAAAiACIAUQAAAAAAAACLAAAABlIAAEFUT1RORVRQUkRDVEFDS0pWU1lEMDJJMTUyRlYuUFJPRFVDVC5BVE9UTkVULkdPVi5BVSNvoQPYkKcmTrssGvhYvtIGer4j7xlNEw==
Result: 401
I need to deploy a RAM Extension that encapsulates an axis2 web service client executing web service calls to SharePoint enforcing NTLMv2 with zero chance of basic / anonymous access.
The core code works 100% using a basic java client wrapper.
When wrapped in the policy extension framework, authentication fails with a 401. I did the instrumentation to make sure the configuration options done through policy extension configuration are being captured and configured correctly. We are using the eWAS bundled with RAM.
However, in doing the packet level trace, I discovered the challenge response from the web service fails and it looks like it's might even be passing it back with a different hashing algorithm?
My main issue is I don't know if any classes are bundled in ewas, or any features like TAI, are enabled that could be disrupting the NTLM auth. Further, the method by which RAM executes the Policy Extension is fairly undocumented and nebulous, so I don't know if there's any additional constraints.
Trace is the following: (C) is for the web service client running in the java wrapper and websphere, (S) is for the SharePoint server.
Client Wrapper
C: Authorization: NTLM TlRMTVNTUAABAAAABnIAAAwADAAgAAAAIgAiACwAAABBVE9UTkVUUFJEQ1RTWUQwMkkxNTJGVi5QUk9EVUNULkFUT1RORVQuR09WLkFV
S: WWWAuthenticate: NTLM TlRMTVNTUAACAAAADAAMADgAAAAGAoECBichviKMTGYAAAAAAAAAANIA0gBEAAAABQLODgAAAA9BVE9UTkVUUFJEQ1QCABgAQQBUAE8AVABOAEUAVABQAFIARABDAFQAAQAWAFMAWQBEADAAMgBJADEANQAyAEYAVgAEACwAcAByAG8AZAB1AGMAdAAuAGEAdABvAHQAbgBlAHQALgBnAG8AdgAuAGEAdQADAEQAcwB5
C: Authorization: NTLM TlRMTVNTUAADAAAAGAAYAEAAAAACAQIBWAAAAAwADABaAQAABQAFAGYBAAAiACIAawEAAAAAAAAAAAAAggIAAO6xkIlyRvP9JczedCS9DF0wqvHsaFUGO6BI34NTop6W0IwRWwdfc+kBAQAAAAAAALBs/hltnswBalIRIQE3UgEAAAAAAgAYAEEAVABPAFQATgBFAFQAUABSAEQAQwBUAAEAFgBTAFkARAAwADIASQAxAD
Result: 200
WebSphere
C: Authorization: NTLM TlRMTVNTUAABAAAABlIAAAwADABCAAAAIgAiACAAAABTWUQwMkkxNTJGVi5QUk9EVUNULkFUT1RORVQuR09WLkFVQVRPVE5FVFBSRENU
S: WWWAuthenticate: NTLM TlRMTVNTUAACAAAADAAMADgAAAAGAoECKyDWBIZvorQAAAAAAAAAANIA0gBEAAAABQLODgAAAA9BVE9UTkVUUFJEQ1QCABgAQQBUAE8AVABOAEUAVABQAFIARABDAFQAAQAWAFMAWQBEADAAMgBJADEANQAyAEYAVgAEACwAcAByAG8AZAB1AGMAdAAuAGEAdABvAHQAbgBlAHQALgBnAG8AdgAuAGEAdQADAEQAcwB5
C: Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHMAAAAAAAAAiwAAAAwADABAAAAABQAFAEwAAAAiACIAUQAAAAAAAACLAAAABlIAAEFUT1RORVRQUkRDVEFDS0pWU1lEMDJJMTUyRlYuUFJPRFVDVC5BVE9UTkVULkdPVi5BVSNvoQPYkKcmTrssGvhYvtIGer4j7xlNEw==
Result: 401