We are running several applications here that allow authentication against our AD server without having an Admin user and password. We simply tell the system the IP address of the Domain Controller and it authenticates for us.
Is there any way to get around the Admin user/pass requirement?
/b
jason
Message was edited by: jase700
Yes, just leave them blank.
is there a fast and easy way to verify the IP address and/or base DNs of our AD install ? like using the ping or ipconfig commands in windows?
I know the NETBIOS address of our AD server…
If you ping the server name, the ip that responds should be the one to use. As far as the baseDN, someone else will need to answer that. Im not sure how that gets configured in AD.
your basedn will not work. It contains spaces
Try using this
As far as pinging goes, you should be able to ping xxxxx.local. That should ping one of your domain controllers. Once you get LDAP working I can show you how to use search to display only active user accounts and even put them into a group and just show the people in the group.
So I now know the IP address, DN’‘s, OU’'s and everything. I have left the admin name and password fields blank, but still no luck.
I just used one of those freeware AD scanners to verify and I have confirmed the IP.
should I remove the password lines altogether?
j
Are you seeing any errors or anything in the log files?
actually, the issue is that I cannot log in at all.
We have two domains, one is a test domain that we have been working off of just fine for some time now. We HAVE a user account on that domain with Admin privileges and use that in the LDAP setup. It is not an exact replica of our live environment.
we know the IP address and DN information for the live server, but do NOT have an admin user account and password for it. I just used one of those LDAP browsers and could see all the user accounts.
Our corporate Wiki uses LDAP autentication to the exact same server we are trying to connect to with NO admin account. We simply put in the IP address and NETBIOS name and it authenticates users with no trouble.
Once I make the changes to my wildfire.xml file to move to the live server’'s IP address, i can no longer log into the admin console or get it to authenticate my client.
This configuration is NOT working… I have tried with and without the OU specified…
Try changing it to:
/code
Seems like an odd difference, I know, but it might work. Thats how we have it.
this thing is still showing me no love…
/code
The AD user you use in the adminDN doesn’'t have to be an AD admin, it just has to be a valid user account so that Wildfire can connect to AD and verify the username and password.
By default AD doesn’'t allow anonymous connections which is why you have to specify some AD account and password.
Here is the error I am getting thrown.
2006.04.06 13:11:18 Created hashtable with context values, attempting to create context…
2006.04.06 13:11:18 Exception thrown when searching for userDN based on username ‘‘adolfj’’
javax.naming.AuthenticationException: LDAP: error code 49 - 80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 525, v893_
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.(Unknown Source)
at org.jivesoftware.wildfire.ldap.LdapManager.getContext(LdapManager.java:271)
at org.jivesoftware.wildfire.ldap.LdapManager.findUserDN(LdapManager.java:445)
at org.jivesoftware.wildfire.ldap.LdapManager.findUserDN(LdapManager.java:400)
at org.jivesoftware.wildfire.ldap.LdapAuthProvider.authenticate(LdapAuthProvider.j ava:88)
at org.jivesoftware.wildfire.auth.AuthFactory.authenticate(AuthFactory.java:114)
at org.jivesoftware.wildfire.admin.login_jsp._jspService(login_jsp.java:134)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:822)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:813)
at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:43)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:813)
at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:813)
at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplica tionHandler.java:813)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler. java:494)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:569)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.ja va:624)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1434)
at org.mortbay.http.HttpServer.service(HttpServer.java:896)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:366)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
/code
That error basicly says the user performing the search dosnt have permissions to do the search. Do you have any ldap browser tools availible? If you have a linux box with ldap-utils you have the commandline ldapsearch tool. I would use one of these to figure out what is going on.