Authentication Service, Mac & PC Management Service
Centrify Infrastructure Services
KB-0217: How sudoers policies maintained by Centrify
How sudoers policies maintained by Centrify
On the Windows side, you set sudo permissions with the Group Policy Object Editor, using the Administrative Template "CentrifyDC Settings" (the template must be added to the Group Policy Object Editor the first time it's used; how to do that can be found in our documentation). You can set sudo permissions on either a per-machine or per-user basis (or both, if you want). In both cases the UI allows to create one or more sudo permissions entries, each of which contains two text fields. However, the meaning of those two text fields is different for machine policies vs. user policies.
For machine policies, the first text box is the name of the user who wishes to run sudo, and the second text box contains the rest of the information that should go into the line in sudoers for that user, except for the "machine=" part (the CentrifyDC GP software fills in the machine name automatically). That generally means the second text box will be of the form "(other_user) command 1, command 2 ...” where "other_user" is the name of the user being sudo'd to (usually root) and "command 1, command 2, ..." are the commands that will be allowed. You can add other information to the line such as a "NOPASSWD:" prefix if you want (see the sudoers (5) manual page on your UNIX/Linux systems for information about what can be specified in the file).
Since user policies apply to each user separately, the name of the user is known automatically. Therefore, the first text box is used for the user being sudo'd to, and the second text box for the list of commands. So you will usually put "root" in the first text box and "command 1, command 2 ...” in the second. As with machine policies, you can put other information such as "NOPASSWD:" in the second text box.
On the UNIX/Linux side, as with all of our Group Policy settings, there is a program, called a "mapper", that runs after each GP update to manage the sudoers file. For machine policies, the mapper is /usr/share/centrifydc/mappers/machine/sudoers.pl. For user policies, the mapper program is /usr/share/centrifydc/mappers/user/sudoers.pl. Those scripts read the sudo permission information from Group Policy and add lines to /etc/sudoers for each entry the administrator created in the Administrative Template as described above. For machine policies, the lines are created when DirectControl is started, and updated on every GP update (every 90-120 minutes by default). If an entry is removed using the Administrative Template, it will be removed from the sudoers file on the next update.
For user policies, lines for the user are added to the sudoers file when the user logs in, and are updated on every GP update as long as the user is still logged in (again, every 90-120 minutes by default). Only users who have logged in to a machine will have lines in the sudoers file on that machine. However, the lines are not removed when the user logs out, because it is possible for a user to appear to be logged out but still have active sessions (via su (1) for example).
The information the administrator enters into the Administrative Template is copied directly into the sudoers file with very little modification, so you can fully control the sudoers file on each machine. Again, see the sudoers (5) manual page on your UNIX systems for full details on what can be specified.