Automic Workload Automation

Hi.  Just wanted to throw this out there and see if anyone has any thoughts / comments on this.  I've searched the HELP and the Community and Knowledge Base, but aren't really finding what I'm looking for, so my guess is that Automic does not support this, but wanted to verify.

As you know in the Automation Engine for security you create users and then to make management easier, put them in user groups.  Lots of ways to make this slightly less of an administrative nightmare.  For one - you can make your system LDAP-enabled so that you don't have to manually reset passwords and such.  When a user logs in they authenticate against Active Directory and that's it.  Nice.

I'm being asked here if Automic can support using Active Directory even more by using security groups within AD to  manage access within Automic.  The end result being that I do a one time create of user groups, but then (this is all theory at this point) I do not create users.  Automic would sync with Active Directory and find the members of the groups and create the users as needed - or perhaps not create the users just put them in the appropriate groups - I don't know.  The point being - it sounds like they want to move management of security of the application out of the scheduling team and let the security team worry about it.

Pretty cool I guess, but from what I've seen I don't think Automic supports this model.  Has anyone else wondered about this, made inquiries about this, know anything that might be coming in the future?

Thanks in advance.

Laura

Hi Larua,

From the sound of your description, it sound like a function the LDAP Sync would do (or at least the closest) - Once setup (and run), it will run against the AD groups that you have configure and sync it to the AE groups (to create any user that in the AD group which is not already in AE).

You would probably need to schedule a job or event to have it run every XX hours to re-sync.  It will update the user base on the AD group you had set up with it (and what groups/permission it would grant to the user on the AE).

Hey Laura,

I would look into the LDAP Sync tool on docs.automic.com to see if it fits this use case. Its looks like exactly what you need though. This tool will map a usergroup in AD to a usergroup in AE and keep the users updated as its a JAR file you can schedule in AE.

Regards,

Michael

Thanks Luu_Le_185  and Michael_Pirson !!  I will take a look at the documentation and see if it's what I need.  Much appreciated!   <3  this forum!

Totally what I was looking for.  This is great!

Have either of you ever done this?  I found another thread https://community.automic.com/discussion/6202/ldapsync#latest on this so I know there are other people out there that have done this, but just a few random questions before I reach out to the AD guy here and start working on this.

- Sounds like new users are created in the <No.Folder> by default.  Do they have to stay here?  Or can they be moved elsewhere?

- How does this work if I currently have users that I created manually and then I enable / start using LDAP Sync?  Anything I need to be concerned about here?  Or just make sure that I have them in the same groups in Automic that they are granted access to in AD and when the first sync happens - no updates will occur?

- Any recommendations on where to put this?  I currently put all my AE components under /u02/automic.  Would it be suggested to create perhaps /u02/automic/LDAPSync and put the jar and xml file here along with the ./clients subdirectory, etc.?  Or should it be somewhere else?

I'm not too sure about the .xml files and how to configure them.  I'm assuming that these will make more sense to my AD guy.

Thanks for all the help.

Hi Laura,

Yoy may also want to read this:
https://community.automic.com/discussion/comment/22863#Comment_22863

I've seen that thread before and re-read - but that's Single Sign On.  I don't think that's what I am trying to do is it?  Sometimes I don't follow the terminology especially if multiple words mean the same thing.  Let me know what I'm missing here Keld_Mollnitz .  Thanks.

Hi Laura,

- Those user object can be move to another folder location within that client.
- If you have already created a user manually (and that user is in the AD group), the ldapsync won't create a new user for it but it  will update user with the permission set (base on your LDAPSync setting).

So for example, lets say the "AD group AA" will have user belonging to the AE permission group AA1.  Then when, it run - if its not in that user group, it will modify it and add it to the usergroup that the you had configure prior.

As for the locations, I recommend making a LDAPSync folder for you, so you can easily tell which component it is and copy the folder/jar file like how it is after you extract it, into that newly created folder.

As for the .xml, for the CN, OU, DC etc.... your AD admin would know more on how to fill that out.   When I did my configuration in house, I just asked my AD admin for the servername, url, username (and the whole CN, OU, DC etc...) and they were able to give it to me for my user account.  The only thing I did was fill in my password and the AE connections information.
(you will enter the password in plain text, but it will be encrypted, once your run it once).

Also as for the "Single Sign-on"  according to our manual it mean:  "Single Sign-on makes it possible to login without having to enter login details."  Which I believe is different then what you are looking to do on your initial post Laura.

Thanks Luu_Le_185.  That make sense.  I appreciate the response.  I will forge ahead!

Hi Laura,

You can use the MOVE_OBJECT command in a Script object to move all USER objects to a designated folder once created in the <No Folder>. Just need to list the USER Object names somewhere to use it as input in a loop to move them.

A bit basic but does the job once it is installed in all clients and can be activated on request, scheduled or in a loading procedure invoking LDAP Sync on a regular basis to refresh userid authorisations and profiles.