Thanks for taking the time to look at this. Since I was using the pkiconsole, I actually had two separate entries: one for all uses (default), and one to deny that particular user, thinking that they will be evaluated together, with deny rules have precedence over allow rules. apparently, I was wrong, please confirm. I've modified the rule to the one you mentioned, but unfortunately it did not accomplish the required result, as well. looking into the debug log, I noticed that profile based enrollment does not get mapped to a specific Authentication or Authorization. so, no matter what ACL I put it will not have any effect. moreover, since the mapping does not exists, even the confi files: acl.properties or auth-method.properties have no effect as well. The last line in the log (preceded by a line of dashes) is somehow confusing, and I was wondering how would you ACL caProfileSubmit through LDAP? isn't the resourceACL LDAP as well?! reference is this REST mapping: https://git.fedorahosted.org/cgit/pki.git/plain/base/common/src/com/netsc... now, the debug log: [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: AccountResource.login() [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: mapping: account [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: loading /usr/share/pki/ca/conf/auth-method.properties [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: checking /var/lib/pki/cse-ca/ca/conf/auth-method.properties [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: required auth methods: [passwdUserDBAuthMgr, certUserDBAuthMgr] [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: authentication manager: certUserDBAuthMgr [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: access granted [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: AccountResource.login() [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: mapping: account.login [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: principal: caagent [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: loading /usr/share/pki/ca/conf/acl.properties [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: checking /var/lib/pki/cse-ca/ca/conf/acl.properties [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: ACL: certServer.ca.account,login [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: checkACLS(): ACLEntry expressions= user="anybody" [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: evaluating expressions: user="anybody" [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: evaluated expression: user="anybody" to be true [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: DirAclAuthz: authorization passed [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: access granted ****BEGIN SEGMENT OF INTEREST**** [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: CertRequestResource.enrollCert() [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: mapping: default [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: required auth methods: [*] [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: authentication manager: certUserDBAuthMgr [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: access granted [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: ACLInterceptor: CertRequestResource.enrollCert() [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: ACLInterceptor: No ACL mapping. ----------------------------------------------------------------------------------------------------------------------------------------------- [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. ****END SEGMENT OF INTEREST**** thanks, On Wed, Apr 29, 2015 at 7:59 PM, Christina Fu <cfu(a)redhat.com&gt; wrote: > Hi, > I was looking for an exact aci syntax example you tried that failed so I > could help you better with. > Did you do something like: > resourceACLS: certServer.ee.request.enrollment:submit:allow (submit) > user!="someBody" && group="Agents":All Agents other than someBody may submit > an enrollment request > > I got the syntax info from the link I gave you. Let me know if that's what > you tried. > > Christina > > > On 04/24/2015 11:14 AM, Ali Khalidi wrote: > > In my test, I've added an user to CM and assigned him Agent group > permissions. > now, I want to deny this user enrollment submission, so there are two > default and pre-existing ACLs of relevance: > certServer.ca.request.enrollment and certServer.ee.request.enrollment > in both I tried the following to the submit right: > change the submit right from allow to deny -> the user can still submit and > enroll a certificate > change back to allow, then added a deny rule with the username specified -> > the user can still submit and enroll a certificate > > these were just experiments to understand how ACLs work. > > my end goal, if possible with dogtag, and I would appreciate if you point me > to the right direction is: > restrict an agent to submit and execute and enrollment based on a specific > certificate profile. > > having said the latter, the user_origreq looked promising for that matter, > but I have no clue how to create a new ACL with it. help is appreciated in > the area as well. > > > Thanks, > > Ali > > > > > > > > On Fri, Apr 24, 2015 at 7:31 PM, Christina Fu <cfu(a)redhat.com&gt; wrote: >> >> On 04/22/2015 02:17 AM, Ali Khalidi wrote: >> >> I've tried a simple example of using the ACL to block profile listing and >> it works. however, I want to disable a CA agent from submitting/approving or >> executing any enrollment requests. I've went through all the ACLs, and >> whenever I encountered a submit right, I flipped to deny. despite that the >> agent still is able to submit and enroll certificates. >> >> information on access control can be found here: >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/... >> >> It would help if you give us an acl example that you tried that does not >> work? >> >> >> another aspect, I was looking into the user_orgreq ACL plugin. can someone >> provide and an example on how this can be used in the context of ACLs? >> >> >> The user_origreq is an access evaluator plugin for the >> UserOrigReqAccessEvaluator. Its primary purpose is for access control >> during renewal. It checks to see the the authenticated user and the >> original request ownership match. >> >> Hope this helps. >> >> >> thanks, >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > >