AD Integration - need answers on some basics

[Carsten Schmitz]

Hi.

I have read the documentation for 11.2 and the overhauled one for 12.3, and I have just written a lengthy email to Automic documentation writers outlining the issues I have with the later still.

But that doesn't really help me, at least not now. As usual, it helps Broadcom :)

I still have very basic questions that maybe someone here can answer:

• Specifically with 12.x, what can LDAP integration actually do for me? Do I still need to create a user objects for every AE user? Or can AE actually authenticate against, say, an AD controller based on AD groups without creating AE users?
  
  
• And if so, how does it actually work, does AE pass the hash of a password I type to the AD controller and the AD controller then says "valid or not"?
  
  The reason I ask this is that the documentation has this odd hint that AD passwords only work if they don't contain any characters disallowed by the AE database schema. This worries me. Why would that be? AE doesn't get to store my AD plain text password, right? With live AD integration, it shouldn't store anything about my passwords, not even hashes, but certainly not passwords!?
• Beyond the documentation being very confusing to me, 12.3 seems to describe an additional tool, but without saying why: LDAPSync.jar. Do I need it? In plain terms, what does it do for me?

In the spirit of Reddit, feel free to answer these questions like I'm five.

Thanks!

[Gang Lu]

Hi Carsten,
LDAPSync creates the users in Automic based on LDAP. In other words, you have to create Automic LDAP users one by one if you do not use LDAPSync.

Regarding to "AD passwords only work if they don't contain any characters disallowed by the AE database schema", my understanding is that the password can be stored temporarily in the database during the authentication.
Best Regards 

[Tim Quakulinsky]

Hi Carsten,

regarding your question:

Specifically with 12.x, what can LDAP integration actually do for me? Do I still need to create a user objects for every AE user? Or can AE actually authenticate against, say, an AD controller based on AD groups without creating AE users?

Yes, you still have to create a user object for every AE user. Authentication via groups does not work.

Best regards,
Tim

------------------------------
Automation Evangelist
Fiducia & GAD IT AG
---
Mitglied des deutschsprachigen Automic-Anwendervereins FOKUS e.V.
Member of the German speaking Automic user association FOKUS e.V.
------------------------------

[Yohan JANOLIN]

Hi Carsten,

LDAPSync allows you to synchronize one or more AD groups with OneAutomation groups either by adding or deleting them
The configuration of the tool is based on a hierarchy of XML files which allows to define different mappings according to the OA' clients
It is even possible to synchronize several ADs with the same OneAutomation system.

All that remains is to plan the execution of LDAPSync, for example, every 5 minutes through OA.

This limits the administration of OneAutomation to the creation of user groups.
The tool will take care of creating or deleting users in OA according to the AD groups they belong to

Note: LDAPSync does not work with client 0000. In addition, LDAPSync uses client 0000 to create users before moving them to their destination client. If the AD user already exists in client 0000, the tool will report an error

Regards,

------------------------------
Solution Architect Automation
Broadcom
------------------------------

[Carsten Schmitz]

Many thanks to all who responded!​

In summary, I understand this as follows:

1. AD integration in the product itself merely authorizes logins against an AD controller.
2. LDAPsync can be scheduled, additionally and optionally, to "farm off" one or more groups on the AD controller and create the respective users in Automic
3. the password is stored in the Automic DB, however briefly

#3 of course raises all sorts of mental red flags with me, seeing that this seems such a pointless thing to do, and Automic having in the past had proprietary crypto, and Automic not revealing it's security methodology or any indenependent code audits, and me having to vouch for the security of the product regardless - but that horse is utterly zombified.

Cheers,
Carsten
​​