Creating admin policy issues

[Sergey Kolosovski]

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 

3)

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

[Cornelius Kölbel]

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.

Am Sonntag, den 10.01.2016, 08:48 -0800 schrieb Sergey Kolosovski:
> 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
> 3)
> 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
Cornelius

> 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...@googlegroups.com.
> To post to this group, send email to priva...@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
corneliu...@netknights.it
+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

[Sergey Kolosovski]

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

On Sunday, January 10, 2016 at 7:43:33 PM UTC+2, Cornelius Kölbel wrote:

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 

http://privacyidea.readthedocs.org/en/latest/policies/admin.html

"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

http://privacyidea.readthedocs.org/en/latest/installation/system/inifile.html#cfgfile

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?

 

[Sergey Kolosovski]

> 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

[Cornelius Kölbel]

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
Cornelius

>
> --
> 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...@googlegroups.com.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/9e8f8255-bddb-479f-86f3-7c48855a5ead%40googlegroups.com.

[Cornelius Kölbel]

Am Sonntag, den 10.01.2016, 10:34 -0800 schrieb Sergey Kolosovski:
> 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
Cornelius

>
> --
> 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...@googlegroups.com.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/df7d5f59-7c50-47f3-9078-5e188e4924ac%40googlegroups.com.

[Sergey Kolosovski]

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... =)

[Sergey Kolosovski]

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.

[Sergey Kolosovski]

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!