Configuring ozone widget framework for ldap authentication

485 views
Skip to first unread message

cripto

unread,
Oct 12, 2014, 2:18:25 PM10/12/14
to ozoneplat...@googlegroups.com
Hello all:

I've been looking all over the web to find a way to configure Ozone for ldap authentication and have failed.


Has anyone else done this. 

This is what I've done so far:

Changed the default url from "localhost" to "my.domain.tld" and resigned all of the default users (testAdmin ....) with a certificated create for "my.domain.tld".

I've looked at ALL of the wiki pages I found on github regarding ldap and they dont seem complete to me (beginner working with ldap).

I also found this link. However I dont get the context of:

I believe its talking about getting the machine hosting owf to authenticate to the server?

If so here is my setup:

Windows 2008 Active Directory server serving on my domain. I've tested that it works by logging into it via both windows and linux machines. I had to use centrify express to join the *nix machines to the domain. 

I can log into the machine hosting Ozone via one of my ldap users and passwords. Does this suffice the three bolted points above? 


Any help would be nice. 

cripto

unread,
Oct 13, 2014, 11:31:07 AM10/13/14
to ozoneplat...@googlegroups.com
Okay, Im getting desperate. Willing to pay a little for a little help. :)

Ross Pokorny

unread,
Oct 13, 2014, 11:48:37 AM10/13/14
to ozoneplat...@googlegroups.com, cripto
The owf-security samples, located in the owf-security folder of the OWF
bundle, include LDAP examples. A few things worth noting:

1. Using LDAP does not inherently require changes to the client certificates.
In fact, LDAP is not inherently tied to using client certificates at all, and
can be used with username/password authentication. As a result, I am unsure
what the purpose of certificate change that you made was.

2. CAS does not need to be involved unless you are trying to create a single-
sign-on solution

3. MS Active Directory has been known to cause difficulties with OWF, compared
to other LDAP servers. You may need to search online for information about
integrating Active Directory with Spring Security (the security framework used
by OWF).

4. Windows Domain authentication is separate, though it is still handled by
Active Directory. Having Domain auth working is unrelated to having LDAP
working with OWF.

5. Changing the default URL of the application is also unrelated to LDAP
authentication.

Ross Pokorny
OWF Developer

On Monday, October 13, 2014 08:31:07 AM cripto wrote:
> Okay, Im getting desperate. Willing to pay a little for a little help. :)
>
> On Sunday, October 12, 2014 11:18:25 AM UTC-7, cripto wrote:
> > Hello all:
> >
> > I've been looking all over the web to find a way to configure Ozone for
> > ldap authentication and have failed.
> >
> >
> > Has anyone else done this.
> >
> > This is what I've done so far:
> >
> > Changed the default url from "localhost" to "my.domain.tld" and resigned
> > all of the default users (testAdmin ....) with a certificated create for
> > "my.domain.tld".
> >
> > I've looked at ALL of the wiki pages I found on github regarding ldap and
> > they dont seem complete to me (beginner working with ldap).
> >
> > I also found this link
> >
<https://tools.codice.org/wiki/display/DDF/Configure+CAS+for+LDAP#Configur
> > eCASforLDAP-ConfigureOzone>.>
> > However I dont get the context of:
> > - Add cas-server-support-ldap-3.3.1_1.jar to CAS
> > <https://tools.codice.org/wiki/display/DDF/Configure+CAS+for+LDAP#Confi
> > gureCASforLDAP-Addcas-server-support-ldap-3.3.1_1.jartoCAS> - Add
> > spring-ldap-1.2.1_1.jar to CAS
> > <https://tools.codice.org/wiki/display/DDF/Configure+CAS+for+LDAP#Confi
> > gureCASforLDAP-Addspring-ldap-1.2.1_1.jartoCAS> - Modify
> > developerConfigContext.xml
> > <https://tools.codice.org/wiki/display/DDF/Configure+CAS+for+LDAP#Confi
> > gureCASforLDAP-ModifydeveloperConfigContext.xml>>

cripto

unread,
Oct 13, 2014, 11:56:37 AM10/13/14
to ozoneplat...@googlegroups.com, joub...@gmail.com
Ross,

Thank you for your reply. I am trying to do single sing on. Basically, the school I work at wants to use OWF to give each student access to their own work space.

1. The certificate change was not for ldap. Once I changed OWF default url from localhost to my.domain.tld, the default users and passwords that came with it did not work. I had to resign them.

2. I am trying to do single signon

3. I saw a few mentions to ApacheDS. Can I configure a relationship between them and then use it apaches? Im locked to using windows because the school uses windows for their ldap.

I agree with 4-5. I was just trying to show where I was. 

Can you point me to a complete guide on setting this up. I feel like all of the wiki pages just mention the configuration files. Even once edited, they cause owf not to come up.

Ross Pokorny

unread,
Oct 13, 2014, 12:07:29 PM10/13/14
to ozoneplat...@googlegroups.com
Could you send the security configuration file that you have so far?

Is the application failing to start up, or simply not letting people log in?
Either way, are there any error messages in the server logs?

It is worth noting that if you are working in a school (university?)
environment, there is likely already a single-sign-on solution set up by the
school, and it would be best to integrate with that instead of the CAS server
that comes with OWF.

Ross Pokorny
OWF Developer

cripto

unread,
Oct 13, 2014, 12:23:13 PM10/13/14
to ozoneplat...@googlegroups.com
Ross,

Thank you for getting back to me. 

I thought ldap was the SSO technology my school was using. If thats incorrect, what are some technologies that they could be using and is there a list of ozone compatible one?


I have been reading this to help me configure Ozone. Specially section 6.6 which has you remove all SecurityContext*.xml files and put in the appropraite one.

I believe that would be OWFsecurityContext_basic_ldap.xml which I copied to the /root/sandbox/apache-tomcat-7.0.21/lib

Below is the configuration file attached. I don't know where to put the url to my AD server. Also in that pdf I attached from redhat, it mentiones apacheds. Is that needed?


<?xml version="1.0" encoding="UTF-8"?>


<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:sec="http://www.springframework.org/schema/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">


<!-- spring beans and security configuration go here! -->

<sec:http>

        <sec:access-denied-handler error-page="/denied.gsp"/>

<sec:intercept-url pattern="/unauthorized.jsp" filters="none" />

        <sec:intercept-url pattern="/js-lib/ext-*/**" filters="none"/>

<sec:intercept-url pattern="/themes/common/images/logout/**" filters="none" />

<sec:intercept-url pattern="/logout.jsp" filters="none" />

        <sec:intercept-url pattern="/administration/monitoring" access="ROLE_ADMIN" />

        <sec:intercept-url pattern="/admin/**" access="ROLE_ADMIN" requires-channel="https" />

        <sec:intercept-url pattern="/**" access="ROLE_USER, ROLE_ADMIN" requires-channel="https" />

        <!-- CUSTOM LOGOUT FILTER -->

        <sec:custom-filter ref="ozoneLogoutFilter" position="LOGOUT_FILTER"/>

        <!-- FILTER THAT CREATES OUR CUSTOM COOKIE -->

        <sec:custom-filter ref="ozoneCookieFilter" before="ANONYMOUS_FILTER"/>

        <sec:form-login />

        <sec:port-mappings>

            <sec:port-mapping http="${ozone.unsecurePort}" https="${ozone.port}"/>

        </sec:port-mappings>

</sec:http>


<sec:authentication-manager alias="authenticationManager">

        <sec:authentication-provider ref="ldapAuthProvider"/>

    </sec:authentication-manager>


    <import resource="ozone-security-beans/OWFLogInOutBeans.xml"/>

    <import resource="ozone-security-beans/ListenerBeans.xml" />

    <import resource="ozone-security-beans/LdapBeans.xml" />

</beans>

Ross Pokorny

unread,
Oct 13, 2014, 1:26:30 PM10/13/14
to ozoneplat...@googlegroups.com
In the context of web applications, SSO refers to a way to have multiple web
apps that the user logs in and out of in unison, so that they only have to
enter their credentials once. This requires an additional web app which hosts
the actual login page and which stores the user's core login session (unit
they logout). The other webapps in the ecosystem communicate with the SSO app
to get information about the current user.

LDAP does not perform the above role, but rather serves as a database of user
information and optionally as a authentication decision-maker. So in a system
using both SSO and LDAP, you would usually have the SSO app configured to look
users up in LDAP. The other individual apps, including OWF in this case,
would not be communicating with LDAP directly but would instead communicate
with the SSO app.

The SSO implementations that I am personally familiar with are CAS (which OWF
uses as an example), and Shibboleth. There are many others; the list on
Wikipedia is fairly extensive:
http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations

OWF could potentially be made compatible with any of these, with varying
amounts of effort - The Spring Security system used by OWF is very extensible.

Ross Pokorny
OWF Developer


On Monday, October 13, 2014 09:23:13 AM cripto wrote:
> Ross,
>
> Thank you for getting back to me.
>
> I thought ldap was the SSO technology my school was using. If thats
> incorrect, what are some technologies that they could be using and is there
> a list of ozone compatible one?
>
>
> I have been reading this
>
<http://people.redhat.com/fcaviggi/OWF/help-3/User%20Guides/OWF%20Configurat
> ion%20Guide.pdf> to help me configure Ozone. Specially section 6.6 which has
> you remove all SecurityContext*.xml files and put in the appropraite one.
>
> I believe that would be *OWFsecurityContext_basic_ldap.xml *which I copied
> to the */root/sandbox/apache-tomcat-7.0.21/lib*

cripto

unread,
Oct 13, 2014, 1:31:57 PM10/13/14
to ozoneplat...@googlegroups.com
Okay Ross,

For now, I'd like to just get ldap login working with my current setup. Do you have any suggestions? What do I need to change from the sample ldap setup I posted earlier.

Thanks for all your help

Ross Pokorny

unread,
Oct 13, 2014, 1:44:07 PM10/13/14
to ozoneplat...@googlegroups.com
Most of the LDAP specific configuration is not in that file, but rather is in the
LdapBeans.xml file referenced in the import elements at the bottom. In that
file you will find spring bean definitions for, among other things, the
ldapAuthProvider referenced in the configuration that you posted, and the
contextSource, which is where the LDAP server URL and root DN are defined.

Ross Pokorny
OWF Developer

cripto

unread,
Oct 13, 2014, 1:52:09 PM10/13/14
to ozoneplat...@googlegroups.com
Oh wow. I didnt even know where that was. Where can I find the documentation for this. I feel bad that I keep bugging you.

How can I find out the values that relate to "o=Ozone,l=Columbia,st=Maryland,c=US" in relation to my ldap server. 

Thank you so much for your help Ross.

Ross Pokorny

unread,
Oct 13, 2014, 2:11:56 PM10/13/14
to ozoneplat...@googlegroups.com
The majority of what is in that file is not OWF-specific, but is general Spring
Security configuration. To gain more understanding, you can start by reading
about Spring's xml bean configuration syntax, if you aren't already familiar
with it. Then, you can look up the JavaDoc of the referenced Spring Security
classes (such as
org.springframework.security.ldap.DefaultSpringSecurityContextSource) online
in order to find descriptions of what they do.

The only OWF-specific part of the file is the reference to
ozone.securitysample.authentication.ldap.OWFUserDetailsContextMapper . You
can find the source code of that class in the owf-security-project.zip (which
is in the owf-security directory of the OWF bundle). It is fairly specific to
the layout of the sample LDAP database that you can find in that same zip file,
in testUsers.ldif. Depending on how similar your LDAP database is to that
sample, OWFUserDetailsContextMapper may or may not be useful to you.

The value that you need to replace "o=Ozone,l=Columbia,st=Maryland,c=US" is
totally dependent on how your LDAP server is configured. It basically
represents the common part of the DN that all other LDAP paths in the
configuration will be relative to - in other words, the partial DN under which
your school keeps all of its user information. I recommend that you contact
your LDAP server's administrator to determine the correct value.

Ross Pokorny
OWF Developer

Joubin Jabbari

unread,
Oct 13, 2014, 2:28:19 PM10/13/14
to
Ross,

Say the ldap configuration was completed properly. What do I do for ozone to give me the login window for ldap rather than cas. right now when I go to my.domain.tld:8443/owf it redirects to my.domain.tld:8443/cas/login?service….

In another word, what is the setting that I need to replace in: OzoneConfig.properties 
ozone.host = owf.mydomain.tld
ozone.port = 8443
ozone.unsecurePort = 8080

#CAS SETTINGS
ozone.cas.serverName=cas
ozone.cas.serverLoginLocation=cas/login
ozone.cas.serverLogoutLocation=cas/logout

#OWF CAS SETTINGS
ozone.cas.owf.serverSecureReceptorLocation=owf/secure/receptor
ozone.cas.owf.jSpringCasSecurityCheckLocation=owf/j_spring_cas_security_check

#MP CAS SETTINGS
ozone.cas.marketplace.serverSecureReceptorLocation=marketplace/secure/receptor
ozone.cas.marketplace.jSpringCasSecurityCheckLocation=marketplace/j_spring_cas_security_check

#METRIC CAS SETTINGS
ozone.cas.metric.serverSecureReceptorLocation=metric/secure/receptor
ozone.cas.metric.jSpringCasSecurityCheckLocation=metric/j_spring_cas_security_check

I have currently setup an ldap server (win 2008) and ozone (debian) at home to get it working and I can present it to them tomorrow. my ldap servers domain is home.mydomain.tld and the machine running owf is owf.home.mydomain.tld 

--
You received this message because you are subscribed to a topic in the Google Groups "ozoneplatform-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ozoneplatform-users/I144DLUpbJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ozoneplatform-users+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ross Pokorny

unread,
Oct 13, 2014, 2:55:05 PM10/13/14
to ozoneplat...@googlegroups.com
> right now when I go to
> my.domain.tld:8443/owf it redirects to
> my.domain.tld:8443/cas/login?service....
It is still redirecting to CAS even with the configuration that you posted
earlier? That is unexpected, and makes me think it isn't really using that
configuration. Are you running from the tomcat that ships with the OWF bundle,
or have you installed OWF into another servlet container? If it is the tomcat
that ships with OWF, make sure that your configuration is in the apache-
tomcat-7.0.21/lib folder, and that no other OWFsecurityContext*.xml files are
in that folder.

Ross Pokorny
OWF Developer

Tina Coleman

unread,
Oct 13, 2014, 2:55:40 PM10/13/14
to ozoneplat...@googlegroups.com

I’ve recently done just such a thing.  Snippeting some code below – this will impact your OzonesecurityContext.xml file.  The OzoneConfig.properties file gives, well, properties to replace items in the various XML configuration files. 

 

<sec:http>

       <sec:form-login login-page="/login/login.html" />                    // line which routes to your custom login page…

     <sec:intercept-url pattern="/login/**" filters="none" />       

  

In this case, I’ve deployed my login file into OWF itself so that I can theme it and “brand” it per my OWF instance.  (Deploying in this case means I drop my HTML files into the login directory…  I believe I originally generated the login page by using Spring’s default login page which it will spit out if you use sec:http and don’t give it the sec:form attribute.  I then saved off its HTML, and ‘skinned it’ the way I wanted…) 

 

Note that I’m also no longer triggering the casProcessingFilterEntryPoint which is listed in the default OWFsecurityContext.xml file.  All auth/auth is handled directly by the OWF app and its interactions with the LDAP repository, rather than doing a handshake mechanism back and forth with the CAS single-signon system. 

 

  

 

Tina Coleman

NEXTCENTURYCORPORATION
7075 Samuel Morse Drive, Suite 250 | Columbia, MD 21046
m 443.545.3100 | f 443.285.0799 |www.nextcentury.com

 

 

 

 

From: ozoneplat...@googlegroups.com [mailto:ozoneplat...@googlegroups.com] On Behalf Of Joubin Jabbari
Sent: Monday, October 13, 2014 2:28 PM
To: ozoneplat...@googlegroups.com
Subject: Re: Configuring ozone widget framework for ldap authentication

 

Ross,

 

Say the ldap configuration was completed properly. What do I do for ozone to give me the login window for ldap rather than cas. right now when I go to my.domain.tld:8443/owf it redirects to my.domain.tld:8443/cas/login?service….

 

In another word, what is the setting that I need to replace in: OzoneConfig.properties 

ozone.host = owf.home.joubin.me

ozone.port = 8443

ozone.unsecurePort = 8080

 

#CAS SETTINGS

ozone.cas.serverName=cas

ozone.cas.serverLoginLocation=cas/login

ozone.cas.serverLogoutLocation=cas/logout

 

#OWF CAS SETTINGS

ozone.cas.owf.serverSecureReceptorLocation=owf/secure/receptor

ozone.cas.owf.jSpringCasSecurityCheckLocation=owf/j_spring_cas_security_check

 

#MP CAS SETTINGS

ozone.cas.marketplace.serverSecureReceptorLocation=marketplace/secure/receptor

ozone.cas.marketplace.jSpringCasSecurityCheckLocation=marketplace/j_spring_cas_security_check

 

#METRIC CAS SETTINGS

ozone.cas.metric.serverSecureReceptorLocation=metric/secure/receptor

ozone.cas.metric.jSpringCasSecurityCheckLocation=metric/j_spring_cas_security_check

 

I have currently setup an ldap server (win 2008) and ozone (debian) at home to get it working and I can present it to them tomorrow. my ldap servers domain is home.mydomain.tld and the machine running owf is owf.home.mydomain.tld 

 

 

On Oct 13, 2014, at 11:11 AM, Ross Pokorny <ross.p...@gmail.com> wrote:



--
You received this message because you are subscribed to a topic in the Google Groups "ozoneplatform-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ozoneplatform-users/I144DLUpbJ4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ozoneplatform-u...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

 

--
You received this message because you are subscribed to the Google Groups "ozoneplatform-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozoneplatform-u...@googlegroups.com.

cripto

unread,
Oct 13, 2014, 3:05:54 PM10/13/14
to ozoneplat...@googlegroups.com
Ross, 

You are right. I moved all of the old xml files to .xmlfiles (hidden) but I guess Ozone was still grabbing them. I deleted them and now Im being redirected to spring login.

Bug I get this error when I try to login:
Your login attempt was not successful, try again.

Reason: Uncategorized exception occured during LDAP processing; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0906DC, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db0]; remaining name 'ou=Users'

Any ideas?

Ross Pokorny

unread,
Oct 13, 2014, 3:31:00 PM10/13/14
to ozoneplat...@googlegroups.com
BIND is LDAP terminology for logging in. In other words, it appears that your
LDAP server requires OWF to authenticate to it before it can perform lookups.
Depending on what it is expecting there are several avenues that you can take
from here. The LDAP server may be expecting the credentials of any actual
human user whose data is in the system. If this is the case, you can pass-
through the credentials from the user when they log in to OWF, and use the
success/failure of the BIND attempt as the basis for OWF's authentication
decision. Alternatively, the LDAP server may be expecting some sort of static
credentials that identify the OWF server (as opposed to a human). If this is
the case, you'll need to configure those credentials within the xml.

Spring supports the first option through
org.springframework.security.ldap.authentication.BindAuthenticator , which you
woud use in place of the PasswordComparisonAuthenticator in the example xml.

The second option is supported through the 'userDn' and 'password' properties
on the contextSource bean.

Since it looks like you'll probably need to have a good understanding of
Spring Security's interaction with LDAP, I recommend that you read
http://docs.spring.io/spring-security/site/docs/3.0.x/reference/ldap.html


Ross Pokorny
OWF Developer

Joubin Jabbari

unread,
Oct 15, 2014, 1:34:27 AM10/15/14
to ozoneplat...@googlegroups.com
Update:

I went through the documentation posted above which resulted in the changes posted below.

However, I keep getting the following error:

Your login attempt was not successful, try again.

Reason: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db0]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db0]

Even though the administrator seen below is correct (I have tested logging into many machines across the network.

I also found this post:

However I can not see how to translate the different config format. 

For instance: the example from the spring page has tags like
<bean:bean ….> </bean:bean>

Where is in the Ldapbean.xml:

We have 
<bean></bean>

What is the difference?


I only add the two user and password lines in the contextSource and nothing else was changed



LdapBean.xml:

    <bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
        <!-- The URL of the ldap server, along with the base path that all other ldap path will be relative to -->
        <constructor-arg value="ldap://home.example.me:389/dc=home,dc=example,dc=me"/>
        <property name="userDn" value="CN=Administrator,OU=DnsAdmins,DC=home,DC=example,DC=me" />
        <property name="password" value="1234Hello1234" />
    </bean>

    <bean id="ldapAuthProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
        <constructor-arg>
            <bean class="org.springframework.security.ldap.authentication.PasswordComparisonAuthenticator">
                <constructor-arg ref="contextSource" />
                <property name="userSearch" ref="ldapUserSearch" />
                <property name="passwordEncoder" >
                    <!-- Probably want to use a more secure PasswordEncoder in a real installation -->
                    <bean class="org.springframework.security.authentication.encoding.PlaintextPasswordEncoder" />
                </property>
            </bean>
        </constructor-arg>
        <constructor-arg ref="authoritiesPopulator" />                       <!-- Populates authorities in the UserDetails object -->
        <property name="userDetailsContextMapper" ref="userDetailsMapper" /> <!-- Adds OWF groups to the UserDetails object -->
    </bean>

    <bean id="authoritiesPopulator" class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
        <constructor-arg ref="contextSource"/>
        <constructor-arg value="ou=owfRoles"/> <!-- search base for determining what roles a user has -->
    </bean>

    <bean id="ldapUserSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
        <constructor-arg value="ou=Users" /> <!-- search base for finding User records -->
        <constructor-arg value="(uid={0})" /> <!-- filter applied to entities under the search base in order to find a given user. 
                                                this default searches for an entity with a matching uid -->
        <constructor-arg ref="contextSource" />
    </bean>

    <!-- Custom class that goes back to the ldap database to search for OWF group records and also adds
         extra attributes from the user's ldap record to the UserDetails object.
         The class implementation of this will likely need to be changed out for differnt setups -->
    <bean id="userDetailsMapper" class="ozone.securitysample.authentication.ldap.OWFUserDetailsContextMapper">
        <constructor-arg ref="contextSource" />
        <constructor-arg value="ou=owfGroups" /> <!-- search base for finding OWF group membership -->
        <constructor-arg value="(member={0})" /> <!-- filter that matches only groups that have the given username listed
                                                      as a "member" attribute -->
    </bean>

    <bean id="ldapUserService" class="org.springframework.security.ldap.userdetails.LdapUserDetailsService">
        <constructor-arg ref="ldapUserSearch" />
        <constructor-arg ref="authoritiesPopulator" />
        <property name="userDetailsMapper" ref="userDetailsMapper" />
    </bean>

</beans>
signature.asc

Ross Pokorny

unread,
Oct 15, 2014, 8:59:28 AM10/15/14
to ozoneplat...@googlegroups.com
The difference between <bean:bean> and <bean> can be ignored for our purposes.
It simply means that the user on that forum has declared his xml namespaces
differently than we have. We are using
"http://www.springframework.org/schema/beans" as the default namespace whereas
he appears to have it set as the "bean" namespace.

More information about the error that you received can be found here:
http://serverfault.com/questions/229887/how-do-i-get-bugzilla-to-authenticate-with-active-directory-ldap . It appears that you may need to specify the
userDn in a different, Active Directory specific format in order to log in to
the LDAP server. I'm have little knowledge of AD, but the first thing that I
would try is a userDn of
"CN=MYDOMAIN\Administrator,OU=DnsAdmins,DC=home,DC=example,DC=me" where
MYDOMAIN is the name of your Windows domain.

Ross Pokorny
OWF Developer

Joubin Jabbari

unread,
Oct 15, 2014, 9:37:55 AM10/15/14
to ozoneplat...@googlegroups.com
Ross. I did what you said, adding HOME before the user. The computers domain is HOME as you can see here: http://puu.sh/cd9Yj/7f30e04e33.png

it is also the subdomain.

After clarifying the namespace, I also this to the top of the file with no effect. Does “DC" vs “dc" matter? 

new Ldapbean.xml:
<bean id="bindAuthenticator" class="org.springframework.security.ldap.authentication.BindAuthenticator">
                <constructor-arg ref="contextSource" />
                <property name="userSearch" ref="userSearch"/>
        </bean>

        <bean id="userSearch"
                        class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
                <constructor-arg>
                        <value></value>
                </constructor-arg>
                <constructor-arg>
                        <value>(sAMAccountName={0})</value>
                </constructor-arg>
                <constructor-arg ref="contextSource" />
                <property name="searchSubtree">
                        <value>true</value>
                </property>
        </bean>

    <bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
        <!-- The URL of the ldap server, along with the base path that all other ldap path will be relative to -->
        <constructor-arg value="ldap://home.example.me:389/dc=home,dc=example,dc=me"/>
        <property name="userDn" value="CN=HOME\Administrator,OU=DnsAdmins,DC=home,DC=example,DC=me" />
        <property name="password" value="1234Hello1234" />
    </bean>

    <bean id="ldapAuthProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
        <constructor-arg>
            <bean class="org.springframework.security.ldap.authentication.PasswordComparisonAuthenticator">
                <constructor-arg ref="contextSource" />
                <property name="userSearch" ref="ldapUserSearch" />
                <property name="passwordEncoder" >
                    <!-- Probably want to use a more secure PasswordEncoder in a real installation -->
                    <bean class="org.springframework.security.authentication.encoding.PlaintextPasswordEncoder" />
                </property>
            </bean>
        </constructor-arg>
        <constructor-arg ref="authoritiesPopulator" />                       <!-- Populates authorities in the UserDetails object -->
        <property name="userDetailsContextMapper" ref="userDetailsMapper" /> <!-- Adds OWF groups to the UserDetails object -->
    </bean>

    <bean id="authoritiesPopulator" class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
        <constructor-arg ref="contextSource"/>
        <constructor-arg value="ou=owfRoles"/> <!-- search base for determining what roles a user has -->
    </bean>

    <bean id="ldapUserSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
        <constructor-arg value="ou=Users" /> <!-- search base for finding User records -->
        <constructor-arg value="(uid={0})" /> <!-- filter applied to entities under the search base in order to find a given user. 
                                                this default searches for an entity with a matching uid -->
        <constructor-arg ref="contextSource" />
    </bean>

    <!-- Custom class that goes back to the ldap database to search for OWF group records and also adds
         extra attributes from the user's ldap record to the UserDetails object.
         The class implementation of this will likely need to be changed out for differnt setups -->
    <bean id="userDetailsMapper" class="ozone.securitysample.authentication.ldap.OWFUserDetailsContextMapper">
        <constructor-arg ref="contextSource" />
        <constructor-arg value="ou=owfGroups" /> <!-- search base for finding OWF group membership -->
        <constructor-arg value="(member={0})" /> <!-- filter that matches only groups that have the given username listed
                                                      as a "member" attribute -->

Ross Pokorny

unread,
Oct 15, 2014, 11:16:59 AM10/15/14
to ozoneplat...@googlegroups.com
LDAP attributes (such as "DN") are not case sensitive.

There are a couple of things wrong with your xml configuration:

1. Simply defining the bindAuthenticator bean is not going to have any effect -
you have to hook it up to actually be used. To do this you would change the
first <constructor-arg> element of the ldapAuthProvider bean so that it has no
contents and has a ref attribute whose value is "bindAuthenticator".

2. You have two FilterBasedLdapUserSearch beans defined - the one that came
with the sample, and the one that you defined. This isn't necessarily a
problem temporarily - just something to be aware of as you ensure that you
wire the beans together correctly. In your final configuration you'll probably
only want/need one.

If you hook up the beans that you have added, here is what will happen with
LDAP when a user tries to log in:

1. A connection will be made to the LDAP server, and a BIND (login) will be
attempted for CN=HOME\Administrator,OU=DnsAdmins,DC=home,DC=example,DC=me with
the password 1234Hello1234.

2. On the connection from step 1, a search will be issued to the LDAP server
looking for users in dc=home,dc=example,dc=me, and subtrees, whose
sAMAccountName matches the username of the person trying to access OWF.

3. Once a matching user is found by step 2, a new connection to the LDAP
server will be created, and a BIND will be attempted on that user from step 2,
using the password supplied by the person trying to access OWF.

4. If the BIND succeeds, the user will be let in to OWF, and if it fails they
will be rejected.

Is this the flow that you are attempting to create? As I mentioned previously,
there are many different ways that this could work, depending on how your LDAP
server is set up. This flow may or may not be suitable, and you may need to
talk with your LDAP administrator to find out how it should work.

Ross Pokorny
OWF Developer
> >> ory -authentication-userdn
> >>
> >> However I can not see how to translate the different config format.
> >>
> >> For instance: the example from the spring page has tags like
> >> <bean:bean ....> </bean:bean>

Joining Jabari

unread,
Oct 15, 2014, 12:27:13 PM10/15/14
to ozoneplat...@googlegroups.com
That is the flow I would like.

For this test I am the ldap admin since they won't give me their domain password. I just need to provide them with a howto.

With that said, I can create users. Groups etc.

Can tell me what users I need to creat to make this flow work?

What would be an equivalent ldapbean file for it.

Sorry to come off so helpless. I just don't understand where things are going wrong.

It seems to me that spring is reaching the server. Just getting wrong credentials in the process. Right?

Ross Pokorny

unread,
Oct 15, 2014, 1:28:48 PM10/15/14
to ozoneplat...@googlegroups.com
So you have admin access to the LDAP server that you are currently working
with? Make sure that the userDn in your contextSource
(CN=HOME\Administrator,OU=DnsAdmins,DC=home,DC=example,DC=me) refers to a user
with permission to perform searches within the "dc=home,dc=example,dc=me"
subtree. Next, make sure that you have a node in that subtree whose
sAMAccountName is the username that you try to login to OWF with, and whose
userPassword attribute is the password that you try to login to OWF with.

Here is a draft of what the LdapBeans.xml file should look like with the
changes I described in my previous email:
xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-3.0.xsd" >
<constructor-arg ref="bindAuthenticator" />
<constructor-arg ref="authoritiesPopulator" />
<!-- Populates authorities in the UserDetails object -->
<property name="userDetailsContextMapper" ref="userDetailsMapper" />
<!-- Adds OWF groups to the UserDetails object -->
</bean>

<bean id="authoritiesPopulator"
class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
<constructor-arg ref="contextSource"/>
<constructor-arg value="ou=owfRoles"/> <!-- search base for
determining what roles a user has -->
</bean>


<!-- Custom class that goes back to the ldap database to search for OWF
group records and also adds
extra attributes from the user's ldap record to the UserDetails
object.
The class implementation of this will likely need to be changed out
for differnt setups -->
<bean id="userDetailsMapper"
class="ozone.securitysample.authentication.ldap.OWFUserDetailsContextMapper">
<constructor-arg ref="contextSource" />
<constructor-arg value="ou=owfGroups" /> <!-- search base for finding
OWF group membership -->
<constructor-arg value="(member={0})" /> <!-- filter that matches only
groups that have the given username listed
as a "member" attribute
-->

</beans>

Yes I believe the first step, where it tries to BIND as
"CN=HOME\Administrator,OU=DnsAdmins,DC=home,DC=example,DC=me" is still what is
failing, due to a credentials problem. Perhaps you could use Wireshark to
watch the LDAP network traffic and see exactly what is getting sent back and
forth.

Ross Pokorny
OWF Developer

Joubin Jabbari

unread,
Oct 15, 2014, 10:14:16 PM10/15/14
to
Ross,

You are completely right. It is hitting the ldap server and getting invalid credentials during the bind. its not even to the point where its checking the credentials that I am putting at the login window via the website. Its just checking the credentials to bind it to the network.

You also notice that Im putting in “tomuser” instead of administrator. Im just doing that incase administrator is only a local user.  I have also attached a screenshot of the “tom users” groups 

With using your template as a guide, I edited my Ldapbean.xml and is attached below.

Here is how tom user is setup inside of ldap:























Packet capture during login: http://puu.sh/cdWRr/e9830b0de6.zip

Note that I changed the url with hex editor. It only confirms that you are right. That I am using the wrong credentials. But I don’t know what else to put in there. 

Thanks for your help

<?xml version="1.0" encoding="UTF-8"?>

        <bean id="bindAuthenticator" class="org.springframework.security.ldap.authentication.BindAuthenticator">
                <constructor-arg ref="contextSource" />
                <property name="userSearch" ref="userSearch"/>
        </bean>

        <bean id="userSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
                <constructor-arg>
                        <value></value>
                </constructor-arg>
                <constructor-arg>
                        <value>(sAMAccountName={0})</value>
                </constructor-arg>
                <constructor-arg ref="contextSource" />
                <property name="searchSubtree">
                        <value>true</value>
                </property>
        </bean>

        <bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
                <!-- The URL of the ldap server, along with the base path that all other ldap path will be relative to -->
                <constructor-arg value="ldap://home.exampl.me:389/dc=home,dc=exampl,dc=me"/>
                <property name="userDn" value=“CN=HOME\tomuser,DC=home,DC=exampl,DC=me" />
                <property name="password" value="1234Hello1234" />
        </bean>

        <bean id="ldapAuthProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
                <constructor-arg ref="bindAuthenticator" />
                <constructor-arg ref="authoritiesPopulator" />
                <property name="userDetailsContextMapper" ref="userDetailsMapper" />
        </bean>




        <bean id="authoritiesPopulator" class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
                <constructor-arg ref="contextSource"/>
                <constructor-arg value="ou=Users"/> <!-- search base for determining what roles a user has -->
        </bean>


<!-- Custom class that goes back to the ldap database to search for OWF group records and also adds
extra attributes from the user's ldap record to the UserDetails object.
The class implementation of this will likely need to be changed out for differnt setups -->
<bean id="userDetailsMapper" class="ozone.securitysample.authentication.ldap.OWFUserDetailsContextMapper">
        <constructor-arg ref="contextSource" />
        <constructor-arg value="ou=Users" /> <!-- search base for finding OWF group membership -->
<constructor-arg value="(member={0})" /> <!-- filter that matches only groups that have the given username listed
as a "member" attribute -->
</bean>



</beans>

--
You received this message because you are subscribed to a topic in the Google Groups "ozoneplatform-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ozoneplatform-users/I144DLUpbJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ozoneplatform-users+unsub...@googlegroups.com.
Screen+Shot+2014-10-15+at+6.29.44+PM.png

Ross Pokorny

unread,
Oct 16, 2014, 8:00:58 AM10/16/14
to ozoneplat...@googlegroups.com
The main difference in the xml that I provided is that I changed

<constructor-arg>
<bean
class="org.springframework.security.ldap.authentication.PasswordComparisonAuthenticator">
<constructor-arg ref="contextSource" />
<property name="userSearch" ref="ldapUserSearch" />
<property name="passwordEncoder" >
<!-- Probably want to use a more secure PasswordEncoder in a
real installation -->
<bean
class="org.springframework.security.authentication.encoding.PlaintextPasswordEncoder"
/>
</property>
</bean>
</constructor-arg>

to

<constructor-arg ref="bindAuthenticator" />

We are reaching the limit of my knowledge, especially since I do not have any
experience with Active Directory specifically. The next thing that I would try
is different formats for the userDn in the contextSource. The forum post that
I linked to earlier - http://serverfault.com/questions/229887/how-do-i-get-bugzilla-to-authenticate-with-active-directory-ldap had several suggestions of
other formats, such as us...@somedomain.local:password . It also includes a
link to a tool that you may find helpful for viewing the layout of your Active
Directory database - http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx

Ross Pokorny
OWF Developer

On Wednesday, October 15, 2014 07:14:10 PM Joubin Jabbari wrote:
> Ross,
>
> You are completely right. It is hitting the ldap server and getting invalid
> credentials during the bind. its not even to the point where its checking
> the credentials that I am putting at the login window via the website. Its
> just checking the credentials to bind it to the network.
>
> You also notice that Im putting in "tomuser" instead of administrator. Im
> just doing that incase administrator is only a local user. I have also
> attached a screenshot of the "tom users" groups
>
> I don't know exactly whats different, but using your template as a guide, I
> edited my Ldapbean.xml and is attached below.
>
> Here is how tom user is setup inside of ldap:
>
>
> Packet capture during login: http://puu.sh/cdWRr/e9830b0de6.zip
>
> Note that I changed the url with hex editor. It only confirms that you are
> right. That I am using the wrong credentials. But I don't know what else to
> put in there.
>
> Thanks for your help
>
> value="ldap://home.exampl.me:389/dc=home,dc=exampl,dc=me"/> <property
> name="userDn" value="CN=HOME\tomuser,DC=home,DC=exampl,DC=me" />
<property
> name="password" value="1234Hello1234" /> </bean>
>
> <bean id="ldapAuthProvider"
> class="org.springframework.security.ldap.authentication.LdapAuthenticationP
> rovider"> <constructor-arg ref="bindAuthenticator" />
> <constructor-arg ref="authoritiesPopulator" />
> <property name="userDetailsContextMapper"
> ref="userDetailsMapper" /> </bean>
>
>
>
>
> <bean id="authoritiesPopulator"
> class="org.springframework.security.ldap.userdetails.DefaultLdapAuthorities
> Populator"> <constructor-arg ref="contextSource"/>
> <constructor-arg value="ou=Users"/> <!-- search base for
> determining what roles a user has --> </bean>
>
>
> <!-- Custom class that goes back to the ldap database to search for OWF
> group records and also adds extra attributes from the user's ldap record to
> the UserDetails object. The class implementation of this will likely need
> to be changed out for differnt setups --> <bean id="userDetailsMapper"
> class="ozone.securitysample.authentication.ldap.OWFUserDetailsContextMapper
> "> <constructor-arg ref="contextSource" />
> <constructor-arg value="ou=Users" /> <!-- search base for finding
> OWF group membership --> <constructor-arg value="(member={0})" /> <!--
> filter that matches only groups that have the given username listed as a
> "member" attribute -->
> </bean>
>
>
>
> </beans>
>
> On Oct 15, 2014, at 10:28 AM, Ross Pokorny <ross.p...@gmail.com>
wrote:

Joining Jabari

unread,
Oct 17, 2014, 12:46:55 PM10/17/14
to
Okay. Update:

I got past all the issues noted above. Now providing my ldap credentials it forwards me to a 500 error. On ie it's just an error page and on Firefox it says "an error has occurred on the server"

There is also a stack trace that says:

Unable to use direct char[] access of Java.lang.string.

I know the ldap part is fine because If I put in invalid password. It returns an error invalid credentials. What is my next step for debugging this?

EDIT: I am actually getting the error as this guy however:


I saw @tinas post in there. I dont know what all I need to change.



Here is some basic info the the ctx variable gets.

https://groups.google.com/forum/#!searchin/ozoneplatform-users/owf$20context$20ldap/ozoneplatform-users/FoKsSFfWulo/mQT9JZ93OPAJ

# example lastname, Users, home.example.me
dn: CN=example lastname,CN=Users,DC=home,DC=example,DC=me
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: example lastname
sn: lastname
givenName: example
distinguishedName: CN=example lastname,CN=Users,DC=home,DC=example,DC=me
instanceType: 4
whenCreated: 20141013044825.0Z
whenChanged: 20141016013101.0Z
displayName: example lastname
uSNCreated: 12687
memberOf: CN=Ozone,CN=Users,DC=home,DC=example,DC=me
memberOf: CN=DnsAdmins,CN=Users,DC=home,DC=example,DC=me
memberOf: CN=Group Policy Creator Owners,CN=Users,DC=home,DC=example,DC=me
memberOf: CN=Domain Admins,CN=Users,DC=home,DC=example,DC=me
memberOf: CN=Enterprise Admins,CN=Users,DC=home,DC=example,DC=me
memberOf: CN=Schema Admins,CN=Users,DC=home,DC=example,DC=me
memberOf: CN=Users,CN=Builtin,DC=home,DC=example,DC=me
memberOf: CN=Administrators,CN=Builtin,DC=home,DC=example,DC=me
uSNChanged: 13105
name: example lastname
objectGUID:: SMhWStxpikKcTxjVGyRZ+Q==
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 130576509177137407
lastLogoff: 0
lastLogon: 130580704003424642
pwdLastSet: 130578966619284862
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAbss3hvRbAuZ+nexFTwQAAA==
adminCount: 1
accountExpires: 9223372036854775807
logonCount: 8
sAMAccountName: example
sAMAccountType: 805306368
userPrincipalName: exa...@home.example.me
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=home,DC=example,DC=me
dSCorePropagationData: 20141015045953.0Z
dSCorePropagationData: 20141013044825.0Z
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 130576508913030405




Thanks.

Ross Pokorny

unread,
Oct 20, 2014, 9:20:41 AM10/20/14
to ozoneplat...@googlegroups.com
Glad you are making progress.

The char[] error can be ignored. It is a bug that occurs in Java 7 as a
result of the version of Groovy that we use. It does not affect actual
functionality since the Groovy runtime catches the exception and then does
what it was trying to do in a different way. Unfortunately it logs the
exception anyway.

You are correct to go searching in the server side log files for the cause of
the 500 error. Keep in mind that, if I recall correctly, tail -f will only
print log messages that occur after you run that command. I would try
accessing the files in a different way. I usually start with a simple ls -l to
see which log files are non-empty. If owf-initial.log or owf-stacktrace.log
are non-empty, you will definitely want to see what is in them. After that I
would check owf-widgeting-framework.log.<date>, and if that still doesn't turn
up anything useful I would check the tomcat logs: catalina.log and
localhost.log . If there are no stacktraces (aside from the char[] error) in
any of those files then something very strange is going on.

Ross Pokorny
OWF Developer

On Friday, October 17, 2014 09:46:42 AM Joining Jabari wrote:
> Okay. Update:
>
> I got past all the issues noted above. Now providing my ldap credentials it
> forwards me to a 500 error. On ie it's just an error page and on Firefox it
> says "an error has occurred on the server"
>
> There is also a stack trace that says:
>
> Unable to use direct char[] access of Java.lang.string.
>
> I know the ldap part is fine because If I put in invalid password. It
> returns an error invalid credentials. What is my next step for debugging
> this?
>
> I did a tail -f logs/* and nothing prints.
>
>
> Thanks.
> >> class="org.springframework.security.ldap.DefaultSpringSecurityContextSour
> >> ce
> >> class="ozone.securitysample.authentication.ldap.OWFUserDetailsContextMapp
> >> er
> >>> xsi:schemaLocation="http://www.springframework.org/schema/beanshtt
> >>> p
> >>>
> >>> ://www.springframework.org/schema/beans/spring-beans-3.0.xsd" >>
> >>>
> >>> <bean id="bindAuthenticator"
> >>> class="org.springframework.security.ldap.authentication.BindAuthenticato
> >>> r"
> >>>
> >>> <constructor-arg ref="contextSource" />
> >>> <property name="userSearch" ref="userSearch"/>
> >>>
> >>> </bean>
> >>>
> >>> <bean id="userSearch"
> >>>
> >>> class="org.springframework.security.ldap.search.Fi
> >>> l

Joining Jabari

unread,
Oct 20, 2014, 11:39:42 AM10/20/14
to ozoneplat...@googlegroups.com
I forgot to update. 


I just need to figure out how to fix it as the first opetion described by Tina is not possible for me. 
--
You received this message because you are subscribed to a topic in the Google Groups "ozoneplatform-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ozoneplatform-users/I144DLUpbJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ozoneplatform-u...@googlegroups.com.

Ross Pokorny

unread,
Oct 20, 2014, 11:48:48 AM10/20/14
to ozoneplat...@googlegroups.com
Notice that the exception comes from OWFUserDetailsContextMapper, a class
which I previously said is custom and is specific to the layout of the sample
LDAP database that we ship. The purpose of this class is to enable you to
retrieve OWF Group information from your LDAP database. If you do not need
this capability, you can simply remove this line from your LdapBeans.xml file:

<property name="userDetailsContextMapper" ref="userDetailsMapper" />

If you do need to do OWF Group mapping, you will need to provide your own
custom implementation of the
org.springframework.security.ldap.userdetails.UserDetailsContextMapper
interface, possibly using OWFUserDetailsContextMapper as a starting point.

Ross Pokorny
OWF Developer
> >>>> class="org.springframework.security.ldap.authentication.BindAuthenticat
> >>>> or
> >>>> ">
> >>>> <constructor-arg ref="contextSource" />
> >>>>
> >>>> <property name="userSearch" ref="userSearch"/>
> >>>>
> >>>> </bean>
> >>>>
> >>>> <bean id="userSearch"
> >>>>
> >>>> class="org.springframework.security.ldap.search.FilterBasedLdapUserSear
> >>>> ch
> >>>> ">
> >>>> <constructor-arg>
> >>>>
> >>>> <value></value>
> >>>>
> >>>> </constructor-arg>
> >>>> <constructor-arg>
> >>>>
> >>>> <value>(sAMAccountName={0})</value>
> >>>>
> >>>> </constructor-arg>
> >>>> <constructor-arg ref="contextSource" />
> >>>> <property name="searchSubtree">
> >>>>
> >>>> <value>true</value>
> >>>>
> >>>> </property>
> >>>>
> >>>> </bean>
> >>>>
> >>>> <bean id="contextSource"
> >>>>
> >>>> class="org.springframework.security.ldap.DefaultSpringSecurityContextSo
> >>>> ur
> >>>> ce
Reply all
Reply to author
Forward
0 new messages