Problem configuring LDAP Authentication

[Gerald Stachl]

I tried to configure LDAP Auth for our Opencast installation. (I followed the instructions on https://docs.opencast.org/r/6.x/admin/configuration/security.ldap/#set-up-an-ldap-provider)

I did this only on our admin-node (I think i have to replicate these steps / copy the files also on our presentation node?) - I hope it should be possible to test it on one node?

After activating the mh_default_org.xml with ldap suport and restarting the services the admin-ui doesn't come up again. Is there any possibility to debug the starting process to find my configuration error?

Thanks for any help

Gerald

[Maxime Pedrotti]

Hello Gerald,

I did this with OC 4.x and 5.x, but I don't think much has changed between 5 and 6.

To get it working in general, it should be enough to set up LDAP auth on the admin node, but as soon as you want to send packages through workflows requiring other nodes (i.e. worker and presentation nodes), you will have to replicate the configuration on these nodes as well. This is because a workflow is usually executed as the user initiating the workflow, and if you start the workflow from the admin node as an LDAP user, it will try to execute jobs on the worker nodes as that same user - if LDAP is not configured on these other nodes, the workflow will fail telling you the user is unknown and/or permissions are missing to execute the job(s) (I had this error as well, and it took me some time to figure out why that was, until I copied the LDAP configuration to the other nodes).

Since you say the admin UI does not start up: My first look would be at the Opencast log file (usually under /var/log/opencast/opencast.log if installed via DEB/RPM packages, or /.../path/to/opencast/data/log/opencast.log if installed from source/tarball, or wherever you may have configured it to log). If your admin node does not start up correctly, there should be warnings or errors after startup, which could help diagnose the cause of the problems.

Best,

Maxime

[Gerald Stachl]

Hello Maxime,

i use Opencast 5.1 - buit the documentation seems to be the same.

I get the following error when starting with LDAP Support:

2018-10-31 19:12:29,331 | ERROR | (?:?) - [org.osgi.service.cm.ManagedServiceFactory, id=423, bundle=152/mvn:org.opencastproject/opencast-userdirectory-ldap/5.1]: Unexpected problem updating configuration org.opencastproject.userdirectory.ldap.0c3d2161-8f6c-4105-a90c-a1e47bcd5b6c

java.lang.IllegalArgumentException: At least one valid attribute must be provided

        at org.opencastproject.userdirectory.ldap.OpencastLdapAuthoritiesPopulator.<init>(OpencastLdapAuthoritiesPopulator.java:93)[152:opencast-userdirectory-ldap:5.1.0]

        at org.opencastproject.userdirectory.ldap.LdapUserProviderFactory.updated(LdapUserProviderFactory.java:257)[152:opencast-userdirectory-ldap:5.1.0]

        at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)[3:org.apache.felix.configadmin:1.8.14]

        at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)[3:org.apache.felix.configadmin:1.8.14]

        at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1624)[3:org.apache.felix.configadmin:1.8.14]

        at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1566)[3:org.apache.felix.configadmin:1.8.14]

        at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)[3:org.apache.felix.configadmin:1.8.14]

        at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)[3:org.apache.felix.configadmin:1.8.14]

        at java.lang.Thread.run(Thread.java:748)[:1.8.0_181]

2018-10-31 19:12:29,591 | INFO  | (RestPublisher:333) - Registered REST endpoint at /admin-ng/users

The LDAP-Part in mh_default_org.xml is:

  <!-- ################ -->

  <!-- # LDAP Support # -->

  <!-- ################ -->

  <bean id="contextSource"

    class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">

    <!-- URL of the LDAP server -->

    <constructor-arg value="ldap://10.1.0.4:389" />

    <!-- "Distinguished name" for the unprivileged user -->

    <!-- This user is merely to perform searches in the LDAP to find the users to login -->

    <property name="userDn" value="cn=ldapuser,cn=Users,dc=ph-noe,dc=ac,dc=at" />

    <!-- Password of the user above -->

    <property name="password" value="xxxxxxxx" />

  </bean>

  <bean id="ldapAuthProvider"

    class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">

    <constructor-arg>

      <bean

        class="org.springframework.security.ldap.authentication.BindAuthenticator">

        <constructor-arg ref="contextSource" />

        <!--

        <property name="userDnPatterns">

          <list>

            <! - - Dn patterns to search for valid users. Multiple "<value>" tags are allowed - - >

            <value>uid={0},ou=Group,dc=my-institution,dc=country</value>

          </list>

        </property>

        -->

        <!-- If your user IDs are not part of the user Dn's, you can use a search filter to find them -->

        <!-- This property can be used together with the "userDnPatterns" above -->

        <property name="userSearch">

          <bean name="filterUserSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">

            <!-- Base Dn from where the users will be searched for -->

            <constructor-arg index="0" value="ou=Mitarbeiter,dc=ph-noe,dc=ac,dc=at" />

            <!-- Filter to located valid users. Use {0} as a placeholder for the login name -->

            <constructor-arg index="1" value="(cn={0})" />

            <constructor-arg ref="contextSource" />

          </bean>

        </property>

      </bean>

    </constructor-arg>

    <!-- Defines how the user attributes are converted to authorities (roles) -->

    <constructor-arg ref="authoritiesPopulator" />

  </bean>

  <!-- #################### -->

  <!-- # OSGI Integration # -->

  <!-- #################### -->

  <!-- Obtain services from the OSGI service registry -->

  <osgi:reference id="userDetailsService" cardinality="1..1"

                  interface="org.springframework.security.core.userdetails.UserDetailsService" />

  <osgi:reference id="securityService" cardinality="1..1"

                  interface="org.opencastproject.security.api.SecurityService" />

  <!-- Uncomment to enable external users e.g. used together shibboleth -->

  <!-- <osgi:reference id="userReferenceProvider" cardinality="1..1"

                  interface="org.opencastproject.userdirectory.api.UserReferenceProvider"  /> -->

  <osgi:reference id="userDirectoryService" cardinality="1..1"

                  interface="org.opencastproject.security.api.UserDirectoryService" />

  <osgi:reference id="authoritiesPopulator" cardinality="1..1"

                  interface="org.springframework.security.ldap.userdetails.LdapAuthoritiesPopulator"

                  filter="(instanceId=phnoe)"/>

and i use the file org.opencastproject.userdirectory.ldap-phnoe.cfg:

##

## ** PLEASE NOTE: EDITING THIS TEMPLATE HAS NO EFFECT!!! **

##

## In order to configure a new LDAP connection, please make a copy of this file in the same directory with the name:

##

##        org.opencastproject.userdirectory.ldap-<ID>.cfg

##

## , where "<ID>" is an identifier, unique for each configured LDAP instance.

## Then, fill in the properties for the new LDAP connection below and ideally delete this header to avoid confusion

## A unique identifier for this connection. It only has effect within Opencast.

## May be different as the <ID> used above, but this is not recommended for clarity

## IMPORTANT: This identifier must be the same as the one used in the security.xml

## file to get a reference to an 'authoritiesPopulator'

org.opencastproject.userdirectory.ldap.id=phnoe

## The URL to the LDAP server

## Example: ldap://ldap.berkeley.edu

org.opencastproject.userdirectory.ldap.url=ldap://10.1.0.4:389

## The user and password used for LDAP authentication.  If left commented, the LDAP provider will use an anonymous bind.

org.opencastproject.userdirectory.ldap.userDn=cn=ldapuser,cn=Users,dc=ph-noe,dc=ac,dc=at

org.opencastproject.userdirectory.ldap.password=xxxxxxxx

## The base path within LDAP to search for users

## Example: ou=people,dc=berkeley,dc=edu

org.opencastproject.userdirectory.ldap.searchbase=ou=Mitarbeiter,dc=ph-noe,dc=ac,dc=at

## The search filter to use for identifying users by ID

org.opencastproject.userdirectory.ldap.searchfilter=(samAccountName={0})

## The maximum number of users to cache

org.opencastproject.userdirectory.ldap.cache.size=1000

## The maximum number of minutes to cache a user

org.opencastproject.userdirectory.ldap.cache.expiration=5

## The comma-separated list of attributes that will be translated into roles.

## Note that the attributes will be converted to uppercase and that they may be prefixed with a string, as defined in the

## configuration below. Please refer to the documentation of the "roleprefix" property below.

## Example: berkeleyEduAffiliations,departmentNumber

org.opencastproject.userdirectory.ldap.roleattributes=

## The organization for this provider

org.opencastproject.userdirectory.ldap.org=mh_default_org

## A prefix to be added to the roles read by this provider. It defaults to an empty string "", i.e. no prefix added.

## Please note that this property had previous a default value of "ROLE_", which is still recommended, but not mandatory.

##

## The prefix is *NOT* added to a role if any of the following conditions is met:

##

##   * The role starts with any of the prefixes defined in the parameter 'exclude.prefixes'

##   * The role was not actually read from the provider, but defined in the 'extra.roles' list below

org.opencastproject.userdirectory.ldap.roleprefix=

## A comma-separated list of prefixes. When the roles read from LDAP start with any of these, then the prefix defined

## above is not prepended to the role.

## Please note that if the "uppercase" parameter was provided, these prefixes are converted accordingly

org.opencastproject.userdirectory.ldap.exclude.prefixes=

## Whether or not the role names should be converted to uppercase. It defaults to "true".

## Please note that this setting affects the prefix defined above.

org.opencastproject.userdirectory.ldap.uppercase=true

## A comma-separated list of extra roles to apply to all the users authenticated with this LDAP instance

## The roles in this list are converted to uppercase if the corresponding parameter is set. However, the 'roleprefix'

## setting does not affect them -i.e. they will not be further modified even if 'roleprefix' is set.

org.opencastproject.userdirectory.ldap.extra.roles=

Have you got any idea what is wrong in my configuration?

[Rute Santos]

Hi Gerald,

    The org.opencastproject.userdirectory.ldap-phnoe.cfg is missing the attribute where the user role is defined in LDAP: org.opencastproject.userdirectory.ldap.roleattributes=ATTR_NAME. Opencast LDAP integration assumes the user dn  has an attribute that contains the user's role(s). Is your LDAP set up in such a way?

    We are also using LDAP for users that log in to the admin UI but, in our LDAP, user dn's don't have a role/group attribute, they are associated to roles/groups via a 'memberUid' attribute in the group dn (ou=Group) so we had to create some custom code to make it work.

    I hope this helps!

    Thanks,

    Rute

--
You received this message because you are subscribed to the Google Groups "Opencast Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@opencast.org.

[Gerald Stachl]

Hi Rute,

thanks for the hint. It solved my problem - Opencast AdminUI ist starting now. I have to think about the association of roles.

Thanks,

Gerald

[Gerald Stachl]

Its getting forward, but LDAP is still not working as expected.

For the moment i use the AD-Field "division" for the role association. My test user has got ROLE_ADMIN there. After Login he is redirected to the Admin-UI, but as you can see in the attached image, there is only an empty UI.

I have got another test user with an empty division entry - He is redirected to the engage-ui (Error-Page) - So it seems to me, that the ROLE_ADMIN is read correctly?

At the moment i've got LDAP Login only on my Admin-Node - so i get an error when i try to login with the "normal user"

Is there a field-Mapping for LDAP Login? (I mean for Email Attribute, Full Name, ...)

Is it correct, that LDAP Logins are not shown in the opencast database?

Thanks for any help

Gerald

[Ruth Lang]

Hi Gerald,

You always need the role ROLE-ADMIN_UI for the admin node, otherwise you will not see anything.

Do really want to give your LDAP user the full rights of an admin ?

The opencast database only contains local users and no users from so called user providers.

Best

Ruth

<opencast_admin_ui.JPG>

[Usman Arif]

Hi, 

I have configure LDAP setting but after that opencast give error forbidden 403. after replacing with mh_default.xml its working fine :( 

[Christian S]

Dear Rute,

could share your custom-Code with us? I try to set up a opencast server with ldap-authentication, but i struggle with the same issues. So i highly would appreatiate your help.

Beste regards!

Christian

Am Mittwoch, 31. Oktober 2018 20:00:15 UTC+1 schrieb Rute Santos:

To unsubscribe from this group and stop receiving emails from it, send an email to us...@opencast.org.

[Fred S.]

Same for me, I've configured CAS / LDAP auth on my Presentation Node, it seems to work ok, but for the Admin Node, it's not working ( Access is denied ).

I think I have to assign a ROLE for an LDAP group to be administrators, but I don't understand how it's working... and didn't find it in the documentation.