I have a server with LDAP, OAUTH2 and TOTP. As per the recommended solution LDAP users are created with obejctGUID as username locally in order to have unique usernames throughout the lifetime of an account.

This causes problems like mentioned in the following topic as well:

However in production system it is not a solution to change this and migrate to sAMAccountName as all current users will loose their current data settings.

Is there another and recommended way making TOTP 2FA work with LDAP and objectGUID as username?

Just to clarify wording, in the ownCloud documentation it calls these UIDs UUIDs instead of GUIDs:

The user in the post you linked was using privacyIDEA.
This solution requires an additional privacyIDEA server.
Looking in the ownCloud marketplace under security, there are also other apps providing 2FA in a similar way (they also need an additional server):

No clue if they have the same restrictions, but I would assume so.

TOTP is an ownCloud internal app., meaning you don’t need an additional server. But this has the downside that users can disable it, and have to enabled it themselves. There is no way to enforce it.

Finally, what is recommended for enterprise environments to enforce 2FA is to setup single-sign-on (SSO), using either SAML2 (ownCloud Enterprise only) or OIDC (also available for Community edition ownCloud). And then use an identity provider (IdP) that supports 2FA, e.g: keycloak or ADFS

Hi Erik,

thanks for the clarification.
By staying at TOTP for a moment, which allows 2FA selected by users (no enforcement). The problem still seems to be the same that starting an auth on the portal with AD username (sAMAccountName) and having UUIDs/UIDs mapped as internal usernames the second factor will fail.

Isn’t it possible to force TOTP to use sAMAccountName for the 2FA?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.