nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

LDAP Authentication Issue

sarkar92

I am using activiti 5.14.
Following is my activiti ldap integration configuration …

  <bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
                <property name="dataSource" ref="dataSource" />
                <property name="transactionManager" ref="transactionManager" />
                <property name="databaseSchemaUpdate" value="true" />
                <property name="mailServerHost" value="127.0.0.1" />
                <property name="mailServerPort" value="25" />
                <property name="jobExecutorActivate" value="false" />
                <property name="configurators">
                  <list>
              <bean class="org.activiti.ldap.LDAPConfigurator">

                <!– Server connection params –>
                <property name="server" value="ldaps://10.0.48.10" />
                <property name="port" value="636" />
                <property name="user" value="cn=admin,ou=services,o=system" />
                <property name="password" value="*******" />

                <!– Query params –>
                <property name="baseDn" value="" />
                <property name="queryUserByUserId" value="(&amp;(objectClass=inetOrgPerson)(cn={0}))" />
                <property name="queryUserByFullNameLike" value="(&amp;(objectClass=inetOrgPerson)(|({0}=*{1}*)({2}=*{3}*)))" />
                <property name="queryGroupsForUser" value="(&amp;(objectClass=groupOfNames)(member={0}))" />

                <!– Attribute config –>
                <property name="userIdAttribute" value="cn" />
                <property name="userFirstNameAttribute" value="givenName" />
                <property name="userLastNameAttribute" value="sn" />

                <property name="groupIdAttribute" value="cn" />
                <property name="groupNameAttribute" value="cn" />

              </bean>
          </list>
        </property>

        </bean>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The integration working fine .

But the issue is while existing ldap user try to login with their "cn" and without "password" user authenticated successfully, which is not good. This thing happen both rest and explorer.
if an existing user try to login with their correct "cn" and without password they are authenticated successfully.
Is it a bug of activiti 5.14 or am i missing some config parameter?

please let me know , its urgent as it is a big security issue.

Find more posts tagged with

Comments

sarkar92

anyone familiar with this issue?

please help…

b_schnarr

I can confirm this. When you enter incorrect username and password, you can not login (ok). When you enter correct username and password, you can login (also ok). But when you enter the correct CN-Username WITHOUT ANY PASSWORD, you can login successfully. Here my config:

<code>
<property name="configurators">
          <list>
              <bean class="org.activiti.ldap.LDAPConfigurator">

                <!– Server connection params –>
                <property name="server" value="ldap://10.120.201.12" />
                <property name="port" value="389" />
                <property name="user" value="cn=Administrator,cn=Users,dc=ebusiness,dc=local" />
                <property name="password" value="****" />

    <!– Query params –>
                <property name="baseDn" value="ou=ebusiness,dc=ebusiness,dc=local" />
                <property name="queryUserByUserId" value="(&(objectClass=person)(cn={0}))" />
                <property name="queryUserByFullNameLike" value="(&(objectClass=person)(|({0}=*{1}*)({2}=*{3}*)))" />
                <property name="queryGroupsForUser" value="(&(objectClass=group)(member={0}))" />
<property name="customConnectionParameters">
     <map>
   <entry key="InitialDirContext" value="Context.REFERRAL" />
    </map>
</property>

                <!– Attribute config –>
                <property name="userIdAttribute" value="distinguishedName" />
                <property name="userFirstNameAttribute" value="givenName" />
                <property name="userLastNameAttribute" value="sn" />

                <property name="groupIdAttribute" value="cn" />
                <property name="groupNameAttribute" value="cn" />

              </bean>
          </list>
</code>

Did we both miss something or is it a severe showstopper bug? Please, this is very urgend. I´m looking forward to hearing from you.

Thanks and best regards
Ben

sarkar92

yes you are right @B.Schnarr..

but no-one from activiti-development team confirm this issue

svenvermeulen

Do you get anything in the logs?

The org.activity.ldap.LDAPUserManager::checkPassword method calls LDAPConnectionUtil.createDirectoryContext but doesn't handle any potential ActivitiException exceptions, whereas LDAPConnectionUtil.createDirectoryContext explicitly throws the proper ActivitiException upon failure. Perhaps the context returned by createDirectoryContext isn't null (even though the password is incorrect) and thus the logic fails.

Can't confirm though, only scarcely looked through the codebase.

sarkar92

there is no error in logs

b_schnarr

I looked through the tomcat logs, but I found no errors.

b_schnarr

I tried to create a Jira Issue, but I cannot Login.

b_schnarr

Activiti Developers,

it is very great that you actually are working on some new great features like multi tenancy. But this severe security issue here leads to the fact that nearly no company can use Activiti in a productive environment. Therefore, please, seriously, a little bit more responses and attention to this issue….

tombo

Hm,
<code>
<property name="queryUserByUserId" value="(&(objectClass=person)(cn={0}))" />
<property name="userIdAttribute" value="distinguishedName" />
</code>
Both attributes related to the user should be the same. This is the source of your troubles. Try with:
<code>
<property name="queryUserByUserId" value="(&(objectClass=person)(cn={0}))" />
<property name="userIdAttribute" value="cn" />
</code>
or other attribute. I'm using sAMAccountName.

Regards,
Boris

b_schnarr

Thank you very much for your answer. The same problem occurs with the following config:

<code>
<property name="configurators">
          <list>
              <bean class="org.activiti.ldap.LDAPConfigurator">

                <!– Server connection params –>
                <property name="server" value="ldap://10.120.201.12" />
                <property name="port" value="389" />
                <property name="user" value="cn=Administrator,cn=Users,dc=ebusiness,dc=local" />
                <property name="password" value="****" />

                <!– Query params –>
                <property name="baseDn" value="ou=ebusiness,dc=ebusiness,dc=local" />
                <property name="queryUserByUserId" value="(&(objectClass=person)(cn={0}))" />
                <property name="queryUserByFullNameLike" value="(&(objectClass=person)(|({0}=*{1}*)({2}=*{3}*)))" />
                <property name="queryGroupsForUser" value="(&(objectClass=group)(member={0}))" />

                <!– Only for Active Directories –>
                <property name="customConnectionParameters">
                <map>
                <entry key="InitialDirContext" value="Context.REFERRAL" />
                </map>
                </property>

                <!– Attribute config –>
                <property name="userIdAttribute" value="cn" />
                <property name="userFirstNameAttribute" value="givenName" />
                <property name="userLastNameAttribute" value="sn" />

                <property name="groupIdAttribute" value="cn" />
                <property name="groupNameAttribute" value="cn" />

              </bean>
          </list>
        </property>
</code>

I also tried with the attributes sAMAccountName and userPrincipalName. As you said, I set those values for both lines you mentionied, e.g.

<code>
<property name="queryUserByUserId" value="(&(objectClass=person)(sAMAccountName={0}))" />
<property name="userIdAttribute" value="sAMAccountName" />
</code>

But the problem is still there. You can successful login without a password.

tombo

Well, well I'm surprised as just tried login with random domain user name. Only user name, without password, is sufficient to be properly authenticated and authorised.
So I must confirm this issue as a third in the row.
It has to do something with AD Kerberos SSO.

Regards,
Boris

b_schnarr

You wrote: "It has to do something with AD Kerberos SSO". We only use an Active Directory on an Windows Server 2008 R2, no technologies with Kerberos SSO. The interesting question is, if this issue occurs with other LDAPs, too?!

tombo

AFAIK, that doesn’t happen with Apache DS LDAP which activiti devs are using for test. My own test confirmed that there is no way to successfully login without password if activiti-explorer is integrated with Apache DS LDAP.

jbarrez

>it is very great that you actually are working on some new great features like multi tenancy. But this severe security issue here leads to the
> fact that nearly no company can use Activiti in a productive environment. Therefore, please, seriously, a little bit more responses and
> attention to this issue….

I understand your concerns. I saw the post the day it was posted, tested it on my unit test and found i could not reproduce it. And apparantly i forgot to answer. Last week was a holiday in most of Europe, and as such not everyone was working. We *do* care about these issues, but I suppose a typical 'big vendor' statement like 'thank you for your issue, our team of highly skilled developers is looking with the utmost attention into it' would be better?

Also: this is an open source forum for an open source project. We don't have every exotic LDAP installation available. We test with Apache DS. We assume it is good enough, cause we are using plain old LDAP bind from the standard JDK way of doing things …. So thank you Tombo for verifying Apache DS already.

I'm looking into it and will post back if I find anything. But I do not have AD installed nor do I have any in-depth knowlegde about it.

b_schnarr

My post was not ment to be malicious and I do not want to criticize anyone. You do great work. I´m just of the optinion that the most used and most important LDAP in productive environments is Active Directory. That is why it would be great if it worked with that.

Thank you for your investigation.
Best regards
Ben

jbarrez

Initial findings after some Googling:

http://stackoverflow.com/questions/12359831/java-ldap-make-it-not-ignore-blank-passwords

"Unfortunately, the authentication with a DN and an empty password is one of the difficiency of LDAP, and results in an "unauthenticated" positive response from the server. Some LDAP servers have configuration options to disable that behavior that has been discouraged in the latest revision of LDAPv3 (RFC 4511), and even have it disabled by default."

Also in the same url:

"You need to change authentication method from simple (which is not something to use in an <b>production</b> environment anyways, at least not without SSL)"

This is possible with the Activiti LDAP integration. Did anyone above try this?

Which leads to the question on how this can be solved from the Activiti side …. or whether it is a configuration option.

jbarrez

Another option could simply be to throw an exception on a blank password …

This could already be done by extending the current LDAP classes and override the methods that are responsible for authentication.

jbarrez

> My post was not ment to be malicious and I do not want to criticize anyone. You do great work. I´m just of the optinion that the most used > and most important LDAP in productive environments is Active Directory. That is why it would be great if it worked with that.

I know that, and we're very grateful for your activity on the forums too. But programming is a funny thing, even with 100's of unit tests there are still cases uncovered. And for these integrations with different systems we also rely on people external to us to validate and tests these things.

And as you can read above, in this case (unless im wrong) it seems to be more on the AD-config side of things.

b_schnarr

To be on the save side: It would be great if Activiti could check if the password field is empty and then, throw a message to the user. I found no option in the Active Directory to disable blank passwords global (for all users). Therefore, would it be possible to add the check if the password field is empty? I know that I could implement it by myself but adding it officially to the distribution would help other peoples, too. What do you think?

jbarrez

Okay, I added it: https://github.com/Activiti/Activiti/commit/09d1858fe4a4e8d74ea86e81c8bbe898fe6ff0e6 and https://github.com/Activiti/Activiti/commit/d7267a27e0dc4f3285dfd715166f2503968ed7f3

As you can see in the commit, it is easy to do that in a custom LDAPUserManager which extends the default one with this extra check. Also the custom LoginHandler is trivial.

b_schnarr

Thank you. According to this: http://technet.microsoft.com/de-de/library/cc816788%28v=ws.10%29.aspx
Anonymous LDAP Binding is disabled by deflaut in Active Directory 2008….This is very strange….

jbarrez

Indeed. And it seems to be enabled on AD 2003.

So by your comment, I assume you are using AD 2008?

b_schnarr

Indeed, this issue seems to be related to Microsoft Active Directory. There are several posts describing that an authentication just with a username and without a password is possible. Seems like a feature and not a bug….Yes, I am using Active Directory 2008

sarkar92

thanks @barrez to commit the changes.
Is it possible to apply the changes in current version 5.14

jbarrez

@sarkar92: we can't retrofix a previous release (and 5.15 is close).
But you can easily extend the current Ldap classes and apply the same fix as I did in the commit above.