Run the Tomcat service using a domain service account. You will need to set the service principal name (SPN) for the service account as noted in the Waffle documentation (waffle/Docs/faq/NegotiateFailsWith401.md at master · Waffle/waffle · GitHub). Make sure that the domain service account has permission to write to the temp, logs, work, etc. in the Tomcat installation directory.
Modify WEB-INF\web.xml to add the <security-constraint> and <security-role> restrictions you want. Place these settings before the first <filter> tag in the file; e.g.:
This example searches the fabrikam.com domain using the specified LDAP auth username and password. Unfortunately, we have to hard-code the LDAP auth account password in xwiki.cfg because the LDAP Authenticator extension requires it. I would recommend restricting access to the WEB-INF directory permissions because of this. (In the future if the LDAP Authenticator extension is updated to be able to perform an LDAP server binding using current credentials, the xwiki.authentication.ldap.bind_DN and xwiki.authentication.ldap.bind_pass settings will not be needed.)
I have successfully set up restricted access using Windows domain authentication using this configuration. I can update this post in case I’ve forgotten any details.
I’m maybe a bit picky about this, but the update is not about “binding without using credentials”, but binding with reusing the container’s user credentials. Binding anonymously (i.e. without credentials) is already supported by the extension, if I read the code correctly, but Active Directory does not allow it.
Binding anonymously (i.e. without credentials) is already supported by the extension, if I read the code correctly, but Active Directory does not allow it.
Since we don’t mind being pedantic (LOL), Actually Active Directory doesn’t allow it by default. It can be configured to allow anonymous binding, but it’s not the default.
I tried to help you getting your point across, because you clearly said “A” while I knew, from your other threads, that you meant “B”. Anybody joining the discussion just now may not have gotten your point.
If you think that is “pedantic”, I’m fine with that, although I may have described it slightly different.
Correct. But let me ask you a question: Why didn’t you configure your active directory to allow anonymous bind, although it would solve your problem (no hard coded passwords), created a feature request for the LDAP Authenticator and currently use a bind DN and a hardcoded password instead?
My guess: Maybe because changing the default and allow anonymous bind, while theoretically possible, is just not a good idea?
But to make our pedantic souls happy I revise my statement:
but Active Directory does not allow almost never allows it. [Assuming production installation, and not some dodgy lab installation].
It’s always enjoyable to interact with someone in a forum who is always right and insists on the last word in every thread
Why didn’t you configure your active directory to allow anonymous bind, although it would solve your problem (no hard coded passwords)
Yes that would solve the problem and you’re right, it’s not a good idea security-wise.
but Active Directory almost never allows it
Again, I would reword this as “Active Directory doesn’t allow anonymous binding by default” or “most Active Directory instances are not going to allow anonymous bindings.”
Just wondered if I could get some help setting up SSO, I’ve followed your configuration steps above but it doesn’t seem to work for me. I’ve enabled debug logging for LDAP and i’m seeing these trace logs. Any ideas?
Thank you for posting this guide! Right now in our deployment we want our webserver logs to capture Active Directory account information in addition to IP address (but we do not want to have XWiki accounts pull from Active Directory). I spent a couple months trying to evaluate the numerous options of integrating Windows authentication. I was unsuccessful in setting up Waffle and all of the solutions which involved Tomcat integration. The only successful solution I was able to implement was to use IIS as a reverse proxy and handle Windows authentication in IIS.
@nha4601
How did you get this to work with reverse proxy?
We’re trying to do the same thing with IIS, but it isn’t passing through the credentials correctly into XWiki.
Tomcat / XWiki isn’t aware of the Active Directory user when using an http reverse proxy. Right now we have separate accounts within XWiki. The main goal behind us using IIS as a reverse proxy was to have the server logs (now in IIS) reflect the Active Directory account for each user request.
We did get a IIS reverse proxy using ISAPI redirector / AJP working which passed the Active Directory user information to Tomcat; however, users with a lot of credentials (OUs) experienced the “request entity too large error”. Increasing the packet size did not solve the issue. We therefore pivoted to using an http reverse proxy instead of ISAPI / AJP.
Our compliance office wanted to be able to log all activity by user. Without the AD account information we would only have IP addresses, which would have to be resolved to machines, then to users.
Our compliance office wanted to be able to log all activity by user. Without the AD account information we would only have IP addresses, which would have to be resolved to machines, then to users.
I just wanted to mention something I forgot to mention before - when integrating Waffle into XWiki on Windows using Tomcat, the Tomcat access log lists the domain username that accesses each page.
I revise my statement:
