-
1. Re: How connect to Active Directory?
1 of 1 people found this helpfulEdit: before reading any of this, make sure to hit LDAP Security Realm Examples. It doesn't deal with Active Directory in specific but does cover the general things I seem to have wasted time typing out below.
I'm slowly trying to condense my process for this into a blog article I want to contribute here because it took me forever to figure out how to do this and a number of things can go wrong in the process. But the short answer is it depends a lot on your Active Directory configuration. I can see some potential trouble spots right off the bat.
First, your authentication <ldap>'s base-dn and your outbound-connections <ldap>'s search-dn are the same. That's most likely incorrect. The authentication <ldap> tells Wildfly where to search for a client's identity and credentials. The outbound-connection <ldap> gives Wildfly the identity and credentials that the SERVER ITSELF is logging in as, so that it can make LDAP queries to authenticate users. Think of the process like this:
1. The server creates a connection to Active Directory and binds as a user (suppose the user name is "wildflysrv"). The server can now make LDAP queries in the Active Directory LDAP tree.
-This is not authenticating or authorizing the user who made a request to Wildfly. This is authenticating Wildfly itself to Active Directory. The outbound-connection <ldap> is what is being used.
2. The server looks for the client's identity and credentials in the LDAP tree. This is the authentication step.
-This is authenticating the user who made the request to Wildfly. The authentication <ldap> is what is being used.
3. The server looks for the client's roles, which will then be applied to whatever resource the user is trying to get to. This is the authorization step.
-This is authorizing the user who made the request to Wildfly. There's an authorization element to the security-realms that needs to be defined, and I never got it to work right.
Given those steps, there's no way base-dn and search-dn are the same. The search-dn should point to the actual user that WILDFLY is going to bind as. This will most likely be a CN entry. Remember I said to assume "wildflysrv" is the user in LDAP that Wildfly is looking for. In this case your search-dn would actually be "CN=wildflysrv,OU=wildfly,DC=tt019,DC=ru". The base-dn should point to a group of users that Wildfly can search. Your base-dn is probably correct.
Now, consider how you're trying to login Wildfly itself. What you've done is attempt to configure a security realm to connect with an LDAP Simple Bind, with no password. I doubt that your Active Directory server will allow you to bind without a password, at least not with default configuration. I would expect your outbound-connection <ldap> to also have a "search-credential" attribute. See Examples - WildFly 8 - Project Documentation Editor for an example of what I'm talking about. This is a plaintext password. But try it with the changes above and see if it works.
If it doesn't, then your situation is that you're not using LDAPS (with SSL), or GSSAPI (which usually means Kerberos with Active Directory), or an encrypted password. Active Directory may not allow this. You can try to define a new security realm with an SSL element, and then reference that new realm with the "security-realm" attribute on your outbound-connection <ldap> to at least enable LDAPS, and that might get you in. But in the end the only way I got this to work was to use the <jaas> element in the realm's <authentication>, and point jaas to a security-domain using AdvancedLdap and Kerberos login modules. I can explain further if your connection isn't working.
You will almost certainly need to switch your console logging to TRACE to get enough console output to see where in the process you're failing. You should also pay close attention to the XML schema found in {jboss.home.dir}\docs\schema\jboss-as-config_2_1.xsd, where the XML elements and attributes for security realms are defined.