Did you modify the source for Wildfire? It does not support NTLM out of the box. In fact, the server is only stating it accepts the PLAIN method. Pandion did the incorrect thing (maybe on purpose?) and send an auth using the NTLM method anyway.
Wildfire as of version 3.0.0 has support for GSSAPI (Kerberos), which in an Active Directory setup is possible to use. But it is very very experimental. No documentation has been written on how to use it (yet! Im working on it!), but if you can read the source you should be able to figure a good chunk of it out. However, GSSAPI and Kerberos are not NTLM. If you are using the older NT style domain, you will need to modify Wildfire to support it. A few people have done this, so it is possible.
What is your native language? Maybe someone here speaks it and can help translate.
Wildfire does not have support for NTLM right now. I know at least one user has added support for it, but other than that I wont be much help for NTLM. Read JM-281 for some more details.
JM-281 I already for a long time read… Initially I have established version 2.6.2, have applied patches and all worked for me in a test mode… Then I have been very borrowed and have not introduced system in public using. About one month I did not concern a server on which worked wildfire, and then have found out that the server does not function… After start service automatically stopped in 3-5 minutes.
Has now seen that in version 3.0.0 have corrected a problem with NTLM and I have decided to reinstall all anew… But now I can not achieve former work automatic login.
I earlier read this topic… On version 2.6.2 at me all has turned out… But then the jabber-server has given failure. Now on version 3.0.0 I can not achieve functionality in any way.
I have updated my libs at http://norman.rasmussen.co.za/dl/sasl-sspi/ to support NTLM in Wildfire 3.0+ for Windows. That should get everyone that was using NTLM in 2.6.2 back on their feet with the new version.
I have tested the plugin. It seems to work fine. I’‘ve also had feedback of it working fine. It gets nuked during the upgrade process, but it’'s easy to add back.
Which version are you using v4 (dll built on aug 20) or v5 (dll built on aug 30)? (v5 got an overhaul to handle exceptions better - it was causing java to segfault - like you describe)
But WF logs are empty (that means no errors are logged in crash time) and Windows Event Log is only said “The Wildfire service entered the stopped state.”
Im afraid that my java skill is very low and now i cant do what you said :-(. But i can do something with step-by-step guide, if you give it to me.
BTW, im to sure what exactly is cause WF to stop and im not blame your patch, may be it`s something in my system cause trouble.
I’'ve been doing some reading and it looks like enabling -XX:+ShowMessageBoxOnError would cause a crash dump to be saved. You may also have to set up Dr Watson to save the dump correctly. If you can get a dump it would greatly help!
Also I think that I must compile a debug version of the dll (with pdb file), so that I can get line numbers - this will also help.
From the stack trace it is my plugin (it shows in the trace). It looks like it’'s passing a null value to the windows system. (but maybe this null comes from Pandion shrug)
Hopefully they’‘ll help someone who’‘s trying to set the parameters on windows (I think on Unix you just set INSTALL4J_ADD_VM_PARAMS, but I’'m not sure if that works on Windows)
Only Free/Delete security buffers that have been used (NT4 fix)
Made a static buffer into a member variable
Assert for Privileges to add SASL methods
Implement getMechanismName
Now built with Java 1.6 (with -source/-target 1.5 for compatibility with Java1.5)
So several memory leaks and threading contention issues have been removed, I haven’'t checked it in my live production Wildfire envionment yet (Java1.5), but it works in my dev testing non-Wildfire/SaslCheck env (Java1.6)