Creating admin policy issues

Hello all
What is a difference between Admin-realm and User-realm within the admin
policy?
Let’s say I want to be able to log in as admin into PI using my LDAP
username and “@admin” suffix appended. I’m creating

  1. user ID resolver which filters only my username
  2. realm “admin” and link in to this resolver

in “/etc/privacyidea/pi.cfg” comment
#SUPERUSER_REALM = [‘super’],
add
SUPERUSER_REALM = [‘admin’]
4) Create a scope admin policy and specify there “admin” as a value of
Admin-realm. There’s a problem. In the Admin-realm list I still have only
"super" realm(WHY?). Then, I include actions, and need to specify a
User-realm. Why if I have already been asked about Admin-realm? And then I
also need to specify resolver. Why again if I already specified User-realm
which already linked to the user-resolver needed?
Then the Admin field. What is this for? To include the PI-internal admin
users to this policy only? Or it could be used somehow to filter users from
the user-resolver which are able to log into this realm?
Could someone assist, because I read the docs and didn’t catch the sence

Hello Cornelius and thank you for the such a rapid and detailed answer,
first of all…

The difference is the following:

The admin-realm would be the realm of the administrator, for whom this
policy fits. The user-realm is the realm of users, the administrator is
allowed to manage.

Now I got it!
It appeared to that I didn’t catch the
7.1. Admin policies — privacyIDEA 3.8 documentation
“All administrative actions also refer to the defined user realm. Meaning
an administrator may have many rights in one user realm and only a few
rights in another realm.”
part. Your explanation here is much clearer for me. I think this is the
right place if you consider to update the doc

Assume you have created a realm and defined this realm to be
administrators.
Then logging in as sergey@admin would give you the role=admin.
Assume you connect to the same LDAP with a realm “users”, then logging
in as sergey@users would link to the same LDAP obejct but would give you
the role=user.

yes, that is what I’m trying to do - under “sergey” I’m able to manage my
own tokens, under “sergey@admin” to manage all the tokens of all users.
Where “sergey” is an LDAP object

There’s a problem. In the Admin-realm list I still have only “super”

realm(WHY?).

The pi.cfg is only read when restarting the Apache server.

Very important note! Suppose it needs to be placed here
2.5. The Config File — privacyIDEA 3.8 documentation
as a note, after “The config file is parsed as python code, so you can use
variables to set the path and you need to take care for indentations.”

And then I also need to specify resolver. Why again if I already

specified User-realm which already linked to the user-resolver needed?

You do not need to specify the resolver. This is optional.

Maybe if you have a good example of why is it needed it could be placed to
the Policy admin doc as well…
Because

Then the Admin field. What is this for? To include the PI-internal
admin users to this policy only?

These are admin usernames. If you want to split this down to admin
accounts.

Could you please clarify here… What if I linked this policy to a
admin-realm which is linked to a resolver which filters a group of LDAP
users. If I specify two names within the Admin field, does it mean that PI
should allow access to this admin realm for only these two LDAP users
specified in the Admin field?On Sunday, January 10, 2016 at 7:43:33 PM UTC+2, Cornelius Kölbel wrote:

Hello Cornelius and thank you for the such a rapid and detailed

    > Then the Admin field. What is this for? To include the
    PI-internal 
    > admin users to this policy only? 
    
    These are admin usernames. If you want to split this down to
    admin 
    accounts. 

Could you please clarify here… What if I linked this policy to a
admin-realm which is linked to a resolver which filters a group of
LDAP users. If I specify two names within the Admin field, does it
mean that PI should allow access to this admin realm for only these
two LDAP users specified in the Admin field?

Thanks for all your valuable feedback on the docs.

The admin-usernames are usernames of the administrators, for whom the
policy should fit.

This is due to the fact, that in older versions there was no
admin-realm.
The logic should be like this:
If you specify the admin-realm, you can further narrow down the
administrators, for whom this policy should fit.

Imagine a realm with users sergey, cornelius and achim.
But as only sergey and cornelius should be allowed to do the defined
administrative tasks, you can add

“sergey, cornelius” as admin-users.

This way admin will not be allowed to administer.

Kind regards
CorneliusAm Sonntag, den 10.01.2016, 10:34 -0800 schrieb Sergey Kolosovski:


You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/df7d5f59-7c50-47f3-9078-5e188e4924ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

The admin-usernames are usernames of the administrators, for whom the
policy should fit.

This is due to the fact, that in older versions there was no
admin-realm.
The logic should be like this:
If you specify the admin-realm, you can further narrow down the
administrators, for whom this policy should fit.

Imagine a realm with users sergey, cornelius and achim.
But as only sergey and cornelius should be allowed to do the defined
administrative tasks, you can add

“sergey, cornelius” as admin-users.

This way admin will not be allowed to administer.

Thanks a lot! Very clear. This is exactly what I was intended to do. But
instead I used LDAP filter like
(|(sAMAccountName=sergey)(sAMAccountName=cornelius))(objectClass=person)
Will test your proposed solution.

There’s a problem. In the Admin-realm list I still have only “super”

realm(WHY?).

The pi.cfg is only read when restarting the Apache server.

I use nginx in my installation. Installed using privacyidea-nginx package
for ubuntu 14.4
Tried to log out, issue “service nginx restart” with OK result, log back in
and in a newly-created admin policy I still only see “super” admin-realm

            > There's a problem. In the Admin-realm list I still
            have only "super" 
            > realm(WHY?). 
            
            The pi.cfg is only read when restarting the Apache
            server. 

I use nginx in my installation. Installed using privacyidea-nginx
package for ubuntu 14.4
Tried to log out, issue “service nginx restart” with OK result, log
back in and in a newly-created admin policy I still only see “super”
admin-realm

Hi Sergey,

with nginx you need in fact to restart uwsgi.
As uwsgi runs the python and nginx is only the HTTP protocol frontend
for the python process in uwsgi.

Kind regards
CorneliusAm Sonntag, den 10.01.2016, 10:40 -0800 schrieb Sergey Kolosovski:


You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/9e8f8255-bddb-479f-86f3-7c48855a5ead%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

Hello Sergey,

thanks a lot for your feedback.
This is your chance to help to improve the docs.
At which part where you expecting this information - so I can add it
there!

The difference is the following:

The admin-realm would be the realm of the administrator, for whom this
policy fits. The user-realm is the realm of users, the administrator is
allowed to manage.

Assume you have created a realm and defined this realm to be
administrators.
Then logging in as sergey@admin would give you the role=admin.
Assume you connect to the same LDAP with a realm “users”, then logging
in as sergey@users would link to the same LDAP obejct but would give you
the role=user.

Hello all
What is a difference between Admin-realm and User-realm within the
admin policy?

Let’s say I want to be able to log in as admin into PI using my LDAP
username and “@admin” suffix appended. I’m creating

  1. user ID resolver which filters only my username
  2. realm “admin” and link in to this resolver

in “/etc/privacyidea/pi.cfg” comment
#SUPERUSER_REALM = [‘super’],
add
SUPERUSER_REALM = [‘admin’]
4) Create a scope admin policy and specify there “admin” as a value
of Admin-realm.

Correct this far. Then your user in this realm would get the role=admin,
when logging in.

There’s a problem. In the Admin-realm list I still have only “super”
realm(WHY?).

The pi.cfg is only read when restarting the Apache server.

Then, I include actions, and need to specify a User-realm. Why if I
have already been asked about Admin-realm?

as mentioned above: THe admin realm only defines, that this policy is
valid for YOUR admin. Assume there are other admins. This policy would
not be for them.

And then I also need to specify resolver. Why again if I already
specified User-realm which already linked to the user-resolver needed?

You do not need to specify the resolver. This is optional.

Then the Admin field. What is this for? To include the PI-internal
admin users to this policy only?

These are admin usernames. If you want to split this down to admin
accounts.

I hope this helps to shed some light.

And I would really appreciate a hint about the location for improving
the docs.
…if it is some other place than the top level policy documentation.
http://privacyidea.readthedocs.org/en/latest/policies/index.html

Kind regards
CorneliusAm Sonntag, den 10.01.2016, 08:48 -0800 schrieb Sergey Kolosovski:

Or it could be used somehow to filter users from the user-resolver
which are able to log into this realm?
Could someone assist, because I read the docs and didn’t catch the
sence

You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/29be2bed-8a67-434e-974f-24269fc93e81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

with nginx you need in fact to restart uwsgi.
As uwsgi runs the python and nginx is only the HTTP protocol frontend
for the python process in uwsgi.

It works!! Thanks a lot! Maybe it’s was not obvious for me as for not an
experienced linux user… =)

I tested with Admin=sergey in admin policy
where “sergey” is a name of AD user
and another usor from the same admin-realm still able to enter the
management interface, however in certain places he get’s an error like a
policy is configured, but the action is now allowed or something similar…

Anyways, I’ll better leave this field(Admin) empty and will filter users
who are allowed to manage PI in User resolver with LDAP filter

Thank you again for the help!