Issues with LDAP users and Duo

[jedunbar]

Elie,

I am having problems with LDAP users logging into ownCloud with the Duo app. Local ownCloud users can log in and 2FA with Duo without a problem. However, LDAP users are presented with error: "Access Denied. The username you have entered cannot authenticate with Duo Security. Please contact your system administrator."

I noticed this (below) on your page...

_LDAP integration

If you're using LDAP, the 2FA won't work right off the bat, since ownCloud refers to LDAP users via their UUID, so I'm not able to pass the plaintext username to Duo, and the authentication fails. See issue #2 for more details.

To change the LDAP settings so that the internal identifier uses the username instead of the UUID, do the following (I'm using AD LDAP, so the attributes are named accordingly): Go into "Expert" mode in the ownCloud LDAP settings, and set "Internal Username Attribute" to "sAMAccountName". Note that this only affects new users. Existing users must be deleted and recreated, so use at your own risk._

I tried this by creating a brand new user account in Active Directory and enrolling them in Duo, but still ran into the Access Denied Duo error mentioned above.

Thoughts? Thanks!

[elie195]

It's been a while since I've touched this code, so I will need to do some tests. From my initial pass over, it looks like the IUser getUID() method is used to retrieve the username. I don't believe there's an alternative built-in method I can use to retrieve the username.

Is this something that used to work and broke recently? Or it never worked for you?

In order to investigate further, I may create a new build with some debug prints so we can figure out what the issue is on your end. I'm running my production ownCloud server with AD LDAP as well, but without any issues.

For now could you please let me know what versions you're using of the following?

• Duo plugin
• ownCloud

[jedunbar]

Elie,

Duo Plugin version: 2.2.0
ownCloud version: 10.0.3 running on Ubuntu Server 16.04.3
Duo MFA has never worked for LDAP users; it's always worked for local ownCloud users.

Aside from from setting the Internal Username Attribute to "sAMAccountName", do I need to change the Login Attributes as well to make this work? (e.g. LDAP/AD Username: , or Other Attributes: sAMAccountName , userPrincipleName )

[jedunbar]

[elie195]

Thanks for the screenshots and info. Try these changes and let me know if it works:

Under "Login Attributes", check both "LDAP / AD Username" and "LDAP / AD Email Address", and don't select any attributes from the "Other attributes" list.

Under "Expert", use "sAMAccountName" for all 3 text boxes (UUID Attribute for Users, UUID Attribute for Groups, as well as Internal Username Attribute)

You might still need to create a new AD user to test, in order for these changes to take effect.

[jedunbar]

Elie,

No joy, unfortunately. I followed your directions and still got the Access Denied error message.

[jedunbar]

I'm not seeing anything in the auth logs in the Duo Admin Panel. Is the Duo plugin logging locally on the ownCloud server anywhere? (e.g. /var/log or /var/www/owncloud)

[elie195]

Hmm, I'm curious if the username passed to Duo is a UUID string or just the username in a format that Duo isn't expecting. I'm working on upgrading and testing on 10.0.3 myself, and then I'll create a build that should print the username passed to Duo in the browser console, in order to confirm the actual behavior.

[elie195]

Ok, quick test. Please make a backup of the apps/duo/templates/challenge.php file and then add the following between the require_once line and the $sig_request line:

function debug_to_console( $data ) {
    $output = $data;
    if ( is_array( $output ) )
        $output = implode( ',', $output);

    echo "<script>console.log( 'Debug Objects: " . $output . "' );</script>";
}

debug_to_console($_['user']);

The entire file should then look like this:

<?php

require_once 'duo/lib/Web.php';

function debug_to_console( $data ) {
    $output = $data;
    if ( is_array( $output ) )
        $output = implode( ',', $output);

    echo "<script>console.log( 'Debug Objects: " . $output . "' );</script>";
}

debug_to_console($_['user']);

$sig_request = Duo\Web::signRequest($_['IKEY'], $_['SKEY'], $_['AKEY'], $_['user']);
script('duo', 'Duo-Web-v2');
style('duo', 'Duo-Frame');
?>

<iframe id="duo_iframe"
    data-host="<?php p($_['HOST']); ?>"
    data-sig-request="<?php p($sig_request); ?>"
    data-post-argument="challenge"
</iframe>

You'll get a code integrity error upon successfully logging in, but that will go away as soon as you revert the file to its original content (this should just look this way for debugging).

Next, attempt to login with an LDAP user. On the Duo challenge page with the error, open up your browser's developer tools and check the web inspector (view the HTML). Unfortunately, I wasn't able to quickly figure out why it's not printing to the console, so the HTML view will have to suffice.

You should see something like the following:

Could you please tell me what you see under the script tag following 'Debug Objects:' ? Is it a long UUID string, or some sort of formatted username?

[elie195]

I found a way to print the user which is a bit simpler: Instead of pasting in that code block, paste this line in instead (in the same location where the previous code block used to be -- between require_once and $sig_request):

p("Username: " . $_['user']);

Then when you attempt to login, you should see the username on the Duo challenge page:

The challenge.php file should look like this:

<?php

require_once 'duo/lib/Web.php';

p("Username: " . $_['user']);

$sig_request = Duo\Web::signRequest($_['IKEY'], $_['SKEY'], $_['AKEY'], $_['user']);
script('duo', 'Duo-Web-v2');
style('duo', 'Duo-Frame');
?>

<iframe id="duo_iframe"
    data-host="<?php p($_['HOST']); ?>"
    data-sig-request="<?php p($sig_request); ?>"
    data-post-argument="challenge"
</iframe>

[elie195]

Hi, were you able to make the changes in order to debug? My guess is that the UUID of the user is passed to Duo, instead of the actual username (as Duo expects).

[jedunbar]

Elie,

Yes. The UUID is being passed instead of the actual username. The only way I've found to get around this is by creating a brand new user, which is not feasible for my environment. I have over 300 users and cannot re-create all of those accounts.

[kinsmen33]

Were also running into the same problem with the UUID / LDAP on an existing implementation. Are there any future plans to link the UUID vs. needing to use the "sAMAccountName" ... or other options?

jedunbar, did you find any other options?

[elie195]

Unfortunately, I can’t really solve this from the plugin side, since I’m using API calls to ownCloud core to retrieve the user info (which returns an ownCloud-specific UUID instead of a username for LDAP users by default).

I was hoping it would be fixed on the ownCloud core side with the following PR, but it looks like it’s been abandoned: owncloud/core#23992

So there’s not much that can be done, since the plaintext usernames for LDAP users just aren’t available via API without setting “sAMAccountName”.

I’m going to close this issue. If/when it will be possible to retrieve the plaintext username for LDAP users via the ownCloud core API, I will revisit this issue.