Using user defined external authentication, OA still verifies local password and fails authentication

[fleitner]

Hello

For my current project I need to authenticate users against an Active Directory. As per customer requirement, only AD users shall be considered, the groups and group membership shall be done within WinCC OA.
The native AD support of WinCC OA fails during setup due to the size of the Active Directory (after a few hours it just stops, having created a mere fraction of the AD groups within WinCC OA). Furthermore, it also pulls all groups from the AD which the customer does not want.

Thus I used the user defined authentication feature to provide my own AD authentication in a control extension which is used in the implementation of my 'OaAuthMethodUserdefined'-class.
However, I run into a few obstacles which leave me puzzled on whether I misinterpret the documentation.


First I implemented the 'getMustCreateUser()' method to return TRUE. Using the login panel I can use my AD credentials to login and a matching WinCC OA user is created. I found some issues on this approach:
* The username appears to be the UPN (User Principal Name) on the AD. In our AD, the email is used. If I try to assign a group to the user, it fails as the username contains invalid characters (@).
* On any subsequent login, OA tries to recreate that user. This fails as the user exist already.
* To add a user to WinCC OA the new user needs to login once before a group can be assigned and the account actually be useful. The desired way is that an administrator can add all required users during initial setup.
(only tested in 3.15 with panel 'vision/loginUserdefined.pnl' as the last point knocks this option out)


Afterwards I tried adding my own 'add user' functionality by modifying the user administration panel (ud_main.pnl) to display a custom AD search dialog upon clicking the "Add" button, which in turn prepopulates the username and fullname properties of the user characteristics panel with information from the AD. Here I can ensure that the OA username is valid, the UPN I store in the full name property.

After assigning a group I can login with that user, my custom authentication takes the fullname property of the user (which is the UPN) and authenticates with the AD. However, one issue I encountered:
My checkUserPassword function returns a "OaAuthenticationError::None".
3.16: In the "login_Standard.pnl" panel this value is received, the method returns true. Somewhere later the password stored in the _Users.Password datapoint is checked and fails the authentication.
3.15: The “vision/loginUserdefined.pnl” panel receives an OaAuthenticationError::UserNotAuth, so the OaAuthenticationError::None returned by my checkUserPassword-function is overwritten somewhere in between

Thus in both cases somewhere after my custom password check OA tries to validate the password with the one stored in _Users.Password, thus failing the authentication.

If I manually crypt(3) the password and store it into the respective _Users.Password field, the login works fine. This verifies that OA tries to validate the password even after the custom checkUserPassword function returns success. Currently I use this as working but insecure workaround for the issue by switching to root after I verify the password and manually set the _Users.Password datapoint to the correct value. This, however, is not an acceptable working solution from a security perspective.

This approach I tried in both 3.15 (vision/loginUserdefined.pnl) and 3.16 (login_Standard.pnl)


This leads me to various questions:
* Why OA tries to validate stored passwords if custom authentication is used?
* How to switch this behaviour off?
* If this is not possible: How do I ensure that the OA password check succeeds if the custom authentication returns OaAuthenticationError::None without using hardcoded root passwords in my checkUserPassword-function?


Best regards
Frank

[Gertjan van Schijndel]

The manager validates the password, because it is unaware that custom authentication is used or that the user is already successfully authenticated by control code.
There is no way to switch off this behavior, otherwise attackers could use this switch, skip the authentication control code and get access to the system.
Directly after the 'checkUserPassword' call 'getMustCreateUser' is checked if this returns TRUE the user (with password) is created in the internal database.

[fleitner]

The manager validates the password, because it is unaware that custom authentication is used or that the user is already successfully authenticated by control code.
There is no way to switch off this behavior, otherwise attackers could use this switch, skip the authentication control code and get access to the system.

That means the custom authentication is next to useless if it can not be used with anything but the internal OA password and the only workaround involves hardcoding the root password in a Control script.

Which in turn leads to an interesting question: If the native WinCC OA Active Directory authentication is used and the password is nontheless stored in the internal OA database, how does OA handle a password change in the Active Directory?
Because that is basically what I'm trying to do. The native WinCC OA Active Directory authentication does not handle our corporate Active Directory, it just fails after having created thousands of internal groups based on the AD groups (still only a fraction of the AD group count).

Directly after the 'checkUserPassword' call 'getMustCreateUser' is checked if this returns TRUE the user (with password) is created in the internal database.

I understand that the user is created the first time, but on the second login OA fails because the user already exist. Do I understand correctly that in 'getMustCreateUser' I have to check the internal database whether the user exists, and return TRUE or FALSE based on the internal OA state?

[Gertjan van Schijndel]

Frank Leitner wrote:

If the native WinCC OA Active Directory authentication is used and the password is nonetheless stored in the internal OA database, how does OA handle a password change in the Active Directory?

After each successful password verification with Active Directory also the internal password is checked and updated if the internal is outdated. The password hash is written to an internal DPE, which triggers a control manager to store it in the internal OA database.

Do I understand correctly that in 'getMustCreateUser' I have to check the internal database whether the user exists, and return TRUE or FALSE based on the internal OA state?

Yes, basically in 'checkUserPassword' the value of 'getMustCreateUser' should be set to 'user.getId() == DEFAULT_USERID'.

[fleitner]

Gertjan van Schijndel wrote:

Frank Leitner wrote:

If the native WinCC OA Active Directory authentication is used and the password is nonetheless stored in the internal OA database, how does OA handle a password change in the Active Directory?

After each successful password verification with Active Directory also the internal password is checked and updated if the internal is outdated. The password hash is written to an internal DPE, which triggers a control manager to store it in the internal OA database.

This is similar to what I am doing right now, writing the crypt(3) password into _Users.Password after the external authentication is successful. I do this directly in the checkUserPassword method, so that the subsequent password check succeeds.
The big issue I have here is that in order to obtain write permissions to _Users.Password, I need to switch to root or another privileged user (via setUserId) which requires the hard coded password in the Control script.

Regarding your second sentence:
* The internal DPE, is this _Users.Password, or another datapoint and the triggered control manager stores it in _Users.Password?
* If the former: How can I write to _Users.Password without having to hard code the password of a privileged user?
* If the latter: Can this automatism be used during custom authentication? If so, is there any documentation for this, or which DPE is to be used?

Do I understand correctly that in 'getMustCreateUser' I have to check the internal database whether the user exists, and return TRUE or FALSE based on the internal OA state?

Yes, basically in 'checkUserPassword' the value of 'getMustCreateUser' should be set to 'user.getId() == DEFAULT_USERID'.

Thank you for the confirmation.

[Gertjan van Schijndel]

Frank Leitner wrote:

* The internal DPE, is this _Users.Password, or another datapoint and the triggered control manager stores it in _Users.Password?

It is another datapoint, which also could be used by a user defined authentication. Unfortunately this is not documented, but you can take a look in the script 'archiv_client.ctl'.

[fleitner]

I'll have a look into that script. Thank you for your help!

[jmad]

The WinCC OA authorization is based on groups from where each user inherits permissions. This is also the reason for trying to catch all Groups from AD first, before a user can be created.

Even when using a user defined external authentication this basic principle of using groups remains valid and therefore it is necessary to configure groups first (eg. assign permission bits) and then create users. This final step of creating users is best done automatically on login of the user (as intended by the login framework). For engineering this means: do all the work of user management in the user management tools (e.g. Active Directory) and do only the unavoidable additional WinCC OA specific configuration on groups (e.g. assigning permission bits to groups) in WinCC OA.

The login framework in WinCC OA 3.16 provides the basic infrastructure especially for the necessary steps of creating internal WinCC OA users upon login (based on the result of getMustCreateUser). When the user logs in, WinCC OA checks the validity of password with the ext Auth (or AD, or OS) and handles the necessary internal structures automatically. When you want to manually intercept this behavior, then you are right, it is a lot of work. For your comfort we provide the login framework to encapsulate those steps.

Please be also aware that the login framework works best with vision/login.pnl which takes care of handling the right login mechanism in the HMI. As I understood you try to use single panels (login_standard.pnl, ...) which is not recommended.

The usage of internal DP structures especially the user management is topic to be changed without further notice (therefore it is internally). Reason for this is our ongoing approach to strengthen security and safety in WinCC OA. Please be aware that direct access to such internal structures might be restricted in (near) future.

I really appreciate your feedback which will help us to improve the interfaces in WinCC OA. Please do not hesitate to get in touch with our consulting team, especially for user management and custom implementation with the ext Auth.

[fleitner]

Hi Jörgen,

thank you for the extensive reply.

There are two main issues with the 'do everything on AD side' approach described by you:

• We have a customer requirement that only the users should get authenticated in the AD. There will be no user groups in the AD matching the user groups required in the OA project. Adding/removing OA access to users shall not involve AD side actions.
  All assignment of users to permissions is to be done in the application. Note the absence of the term 'group', which causes an issue when combining with the group based permission system of OA.
  
  In this context the 'getMustCreateUser' - feature creates a weird workflow: In order to allow a user access to OA, said user would have try to to login with OA first, only than an admin can assign groups to the user. The customer requires that an OA administrator can setup new OA users as single workflow prior to the first OA login of that user.
  
  Thus our intended workflow is (steps 1 and 2 only during initial setup):
  [ol]
• Creation of user groups in WinCC OA
• Assigning permission bits to these groups
• Creating OA users based on AD users, and assigning them to the OA groups
• [/ol]
• At least for our corporate directory the number of groups in the AD appear to outweigh the capabilities of OA: Switching to the native AD authentication syncs groups up to starting letter 'd' (iirc) and then silently fails, preventing any assignment of permission bits to most of the groups

I'm on holidays the next week (yeah), I'll have a look into vision/login.pnl and the login framework afterwards. Thanks for the pointer.


Best regards
Frank

[kilianvp]

we just need AD query filters.

when 3.16 gets LDAP support?