Hi,

I’m not an expert on Active Directory. But I can answer from a general point of view first.

There are 4 main categories for authentication: https://reference.opcfoundation.org/Core/Part4/v104/docs/7.36.1 ” AnonymousIdentityToken No user information is available.
UserNameIdentityToken A user identified by user name and password.
X509IdentityToken A user identified by an X.509 v3 Certificate.
IssuedIdentityToken A user identified by a token issued by an external Authorization Service.
“
This is what you will get from the SDK, e.g. see MyUserValidator in the sampleconsoleserver example. How to validate that information is something you must do on the application level (and how exactly is up to you).

Then authorization. Technically nowadays OPC UA does specify Part 18 Roles: https://reference.opcfoundation.org/Core/Part18/v105/docs/, but it is not widely supported yet (we also do not yet support this). This was introduced in OPC UA 1.04. However, even before that there are “normal user access controls” (i.e.. UserAccessLevel, UserWriteMask, UserExecutable Attributes) which we do support via XXXListener e.g. IoManagerListener (Read/Write; see MyIoManagerListener again in the sampleconsoleserver), you can obtain the user identity who made the call via first parameter to those listener methods i.e. ServiceContext.getSession().getUserIdentity(). See the MyNodeManagerListener.onBrowseNode for equivalent for the Browse service call.

The terms ‘Kerberos’ and ‘LDAP’ come up related to Active Directory. Not sure can you do this with LDAP alone, or what exactly you would want.

For the IssuedIdentityToken there are some type definitions. Historically there was also rules for a ‘Kerberos’ token, but it is deprecated in OPC UA 1.05 https://reference.opcfoundation.org/Core/Part6/v105/docs/6.5.1 (could have been unrelated also). Basically not many OPC UA applications support the IssuedIdentityToken. If you need to do something manually with it the interoperability with other clients might be poor. If you do not need that, then it is ok (interoperability is a key OPC UA feature, so in general I wouldn’t recommend this to be the only authentication mode). Though I do not recall any real use-case where the IssuedIdentityToken would actually have been used. It is mostly just the AnonymousIdentityToken and app-level authentication (i.e. both sides must trust the other side ApplicationInstanceCertificate for security modes other than NONE), then simple username+password and in some rare cases the X509IdentityToken (i.e. user cert, similar to e.g. adding a public key when using Git as version control).

For LDAP, since (per https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) the LDAP client in BIND just sends the DN+password to the server, this is basically external to the SDK. You can look at MyUserValidator in the sampleconsoleserver (and somehow transform the username to the DN; this has nothing to do with OPC UA, so I would assume the internet provides generic solutions e.g. if the username is an email address etc.). Username+Password is much more common and would be more interoperable among the worlds OPC UA Clients.

Does this help?