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

[jmad]

Thanks for your details. I hope you can enjoy your vacation and come back with ideas later. For the moment I just drop some lines, maybe they can be helpful.

Addressing the design not using 'full' AD, just users but no groups, leads to the usage of the userdefined ext. Auth feature.

From a distant point of view your approach on using AD for authenticating users is possible. I also understand the three steps in engineering.

Step 1: Creating Groups in WinCC OA --> ok. always possible
Step 2: Assigning Bits (aka roles) to groups --> ok. standard use case
Step 3: Create Users locally and assign them to groups, but authenticate against AD --> ok, but non-standard.

To solve step 3 it is possible to rely on the feature of updating WinCC OA user database automatically after successful login. Hence it is possible to update local users after successful authentication with an external tool (as we do with our AD). You can prepare users with random password and let the system do the update. The difference between our standard AD solution and your requirement is, that you must not create users, just update them.

The following engineering workflow is possible:
3 Steps as recommended by your customer --> ok

For implementation I would recommend to inherit as much as possible from the standard framework classes und just maintain the authentication and update user portions. You can use verifyOSUser() when the PC is part of the AD domain for authentication purposes and continue with the result inside the framework.

The following sequence takes place during login:
[ol][*] user provides username / password [*]
[*] the ext Auth implementation checks the password with AD and reports back success or failure (e.g. verifyOSUser() )[*]
[*] SUCCESS: login framework updates internal WinCC OA structures (without using them any longer) and proceeds with authenticated operation. users are in place, authenticated and get bits from already existing groups [*]
[*] FAILURE: Access denied and no further updates or other activities [*][/ol]

Regarding the size of enterprise AD structures, yes it can take ages (hours+). But I have never seen a failure. When you have that in a reproducible way (for reproducing on ETM side) please report a bug.

Enjoy your holidays!

[fleitner]

Jörgen Mad wrote:

Regarding the size of enterprise AD structures, yes it can take ages (hours+). But I have never seen a failure. When you have that in a reproducible way (for reproducing on ETM side) please report a bug.

Hi Jörgen,

to answer just on that part:
When I switched to AD authentication, the UI became unresponsive. I let my machine run overnight, the next morning the UI appeared normal again, no activity was noticeable.
However, only groups with starting characters a-d as well as underscore (and perhaps some other non-alphabetic characters, I don't recall) were created. This I tried twice, with the similar result (IIRC on the second try it fetched groups up to 'e').

I used the Siemens AD (ad001.siemens.net), so I'd assume the same should happen if you try it on your side.

Best regards
Frank

[Gertjan van Schijndel]

Frank Leitner wrote:

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

Instead of implementing the authentication from scratch, you could derive your authentication from the AD authentication class and only re-implement/overrule the group functions.

[kilianvp]

Frank Leitner wrote:

Jörgen Mad wrote:

Regarding the size of enterprise AD structures, yes it can take ages (hours+). But I have never seen a failure. When you have that in a reproducible way (for reproducing on ETM side) please report a bug.

Hi Jörgen,

to answer just on that part:
When I switched to AD authentication, the UI became unresponsive. I let my machine run overnight, the next morning the UI appeared normal again, no activity was noticeable.
However, only groups with starting characters a-d as well as underscore (and perhaps some other non-alphabetic characters, I don't recall) were created. This I tried twice, with the similar result (IIRC on the second try it fetched groups up to 'e').

I used the Siemens AD (ad001.siemens.net), so I'd assume the same should happen if you try it on your side.

Best regards
Frank

true i reported that bug one year ago via Siemens Support. In the current state the feature is pretty useless. Most of my customer have a very big AD. I thought Siemens will add LDAP support to 3.16 with AD filters...