Granting Access to Package Manager

[jforney]

I'm trying to wean myself off of use of the admin account as the account used to connect to AEM via batch processes.  One of these processes is a script that builds our AEM application out of SVN and deploys it to our production CQ instances.  I create a new account I call "service" and did my level best to make it look identical to the admin account in user management.  Yet I find when my script gets to the step that does the deployment and where the admin account was able to successfully upload the CQ package to both the PRD authoring and publishing instance the new service account always fails to deploy to any publishing instance but always is successful to any authoring instance.  Investigating this I find that when I go into package manager using the service account on an authoring instance I can see all of the packages sitting in package manager.  When I try the same thing on one of my publishing instances (and it doesn't matter which one I choose) I never see and packages sitting in package manager.

This get's me thinking there is yet some difference between the out-of-box admin account and my service account that I'm unable to detect via user management.  I wondering if there is some package manager ACL I need to specifically grant to my new service account on my publishing instances so that it can see packages and upload packages..

[Sham_HC]

In publish you can use WCM user management . Try with http://<host>:<port>/libs/cq/security/content/admin.html

[Paul_McMahon · Accepted solution]

Is your service user a member of the administrators group? I believe that there are some deny nodes under rep:policy for / in publish instances that cause problems for publish users who aren't part of the administrators group. I also assume that you activated your service user and all it's groups to the publish server. 

[jforney]

Thanks for the information on how to get to WCM, User Management on a publishing instance.  I'd also placed this question in DayCare and they were able to tell me that I need to check ACLs on /etc/package node on my admin-like account.  Apparently there is a minor difference between administrators group on authoring instance versus publishing instance as you inherit no read ACL on /etc/package node from administrators group on publishing instances.  This is what prevents one from uploading any packages with an account that is member of administrators group on publishing instances.  Seems actually there is a global (everyone) deny on read ACL of /etc/packages that is the true cause of the issue.  If you bring up your admin-like account in user management and drill down to /etc/packages you can manually override this global deny for your admin-like account and then all will be well.

[jforney]

I didn't activate my "service" user to get it to appear on the publishing instance but rather I used user management through the CRX console to create the account in the publishing instances.  In all cases I added the "administrators" group to the list of groups the "service" account is a member of.  The one thing I can tell you that was different about the way I created the "service" user in the publishing instance versus the way I did it in author is that in author, because I'm using the WCM user management I have the "Permissions" tab that allowed me to verify that my "service" user indeed had all ACLs checked off at the highest folder levels in this "Permissions" tab just like what you find with the "admin" account.  I wasn't able to do this in publish because the CRX Console's user management doesn't offer this same view.  So therefore I could only assume that my "service" account in the publishing instances inherited all the same ACLs from being a member of the administrators group; I couldn't actually confirm it be looking at a view similar to the "Permissions" tab in WCM user management.  CRX Console user management simply doesn't have that view.

Now that I've told you they way I got the "service" account in the publishing instances do you think I would be better served by deleting my "service" accounts that I created via CRX Console user management in the publishing instances, returning to author instances and activating the "service" account on the authoring instance so that replication agents can publish my "service" account to the publishing systems?  I'm not sure I know how to activate/publish an account as I would generally do that action as an author in WCM's Websites area but as you know you can't see the /home/* area where accounts live from that view.  How would you go about activating/publishing an account?