mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
lots of minor tweaks and updates
This commit is contained in:
Fraser Tweedale
Alexander Bokovoy
parent
0678ed5649
commit
3a0f8a114b
@ -106,7 +106,9 @@ workshop) and accept the defaults for configuring the reverse zone::
|
||||
Do you want to configure DNS forwarders? [yes]: no
|
||||
No DNS forwarders configured
|
||||
Do you want to search for missing reverse zones? [yes]:
|
||||
|
||||
Do you want to create reverse zone for IP 192.168.33.10 [yes]:
|
||||
Please specify the reverse zone name [33.168.192.in-addr.arpa.]:
|
||||
Using reverse zone(s) 33.168.192.in-addr.arpa.
|
||||
|
||||
Next, you will be presented with a summary of the server
|
||||
configuration and asked for final confirmation. Give confirmation to begin the
|
||||
@ -118,10 +120,15 @@ server installation::
|
||||
Domain name: ipademo.local
|
||||
Realm name: IPADEMO.LOCAL
|
||||
|
||||
The CA will be configured with:
|
||||
Subject DN: CN=Certificate Authority,O=IPADEMO.LOCAL
|
||||
Subject base: O=IPADEMO.LOCAL
|
||||
Chaining: self-signed
|
||||
|
||||
BIND DNS server will be configured to serve IPA domain with:
|
||||
Forwarders: No forwarders
|
||||
Forward policy: only
|
||||
Reverse zone(s): No reverse zone
|
||||
Reverse zone(s): 33.168.192.in-addr.arpa.
|
||||
|
||||
Continue to configure the system with these values? [no]: yes
|
||||
|
||||
@ -129,7 +136,7 @@ The installation takes a few minutes; you will see output indicating
|
||||
the progress.
|
||||
|
||||
When it completes, run ``kinit admin`` and enter your *admin*
|
||||
password to obtain a Kerberos ticket granting ticket (TGT) for the
|
||||
password to obtain a Kerberos *ticket granting ticket* (TGT) for the
|
||||
``admin`` user::
|
||||
|
||||
[server]$ kinit admin
|
||||
|
||||
@ -42,7 +42,7 @@ Generate a user keypair on the client system::
|
||||
Your identification has been saved in /home/alice/.ssh/id_rsa.
|
||||
Your public key has been saved in /home/alice/.ssh/id_rsa.pub.
|
||||
The key fingerprint is:
|
||||
SHA256:TbuWICAdqkdXwG3uQoXxh03DuJdRC6Vh3ntOcacdfHM alice@ipademo.local
|
||||
SHA256:KZ1MQCvaGAGZxKaMxmWBexzH98NPBsTsuo1uf/42SB0 alice@ipademo.local
|
||||
The key's randomart image is:
|
||||
+---[RSA 2048]----+
|
||||
| .+=.o*oo |
|
||||
@ -62,6 +62,7 @@ entry in FreeIPA::
|
||||
|
||||
[alice@client]$ kinit alice
|
||||
Password for alice@IPADEMO.LOCAL:
|
||||
|
||||
[alice@client]$ ipa user-mod alice \
|
||||
--sshpubkey="$(cat /home/alice/.ssh/id_rsa.pub)"
|
||||
---------------------
|
||||
@ -78,14 +79,14 @@ entry in FreeIPA::
|
||||
SSH public key: ssh-rsa
|
||||
AAAAB3NzaC1yc2EAAAADAQABAAABAQDH8pLi61DjkEPqNZnfOgGLLZfLdu9EqVL9UrZeXD3M/j3ig+xeDCCO80YjzuND0UZE4CHgA+uGrtoinQMYkt/FRkm/ie8wcinP/8BxSoOeYSHDNG+cG3iSNJrDiHoqPeQ/+nzBS5n6HWy18N5IMNoqC+f9f2VDuHWZCKqPHMLD29MAX6vOgawdHWFcAk416O+EgS43w3ub89+VPz3Egz4z9K+gjpoboFHk94n7n09B+qyzzImVMsz9vMFSr0rcaVRd9Tb0Q6HlUXkU7aH1Vjkl/DJdQalCpPYJXujkRYAZIs1ouU5IBuuq6k54fk1vBmwjv2tK2NkpvfWfhaxQVwdn
|
||||
alice@ipademo.local
|
||||
SSH public key fingerprint: C4:62:89:7A:65:F9:82:12:EF:08:96:D1:C9:7D:51:A5 alice@ipademo.local
|
||||
(ssh-rsa)
|
||||
Account disabled: False
|
||||
Password: True
|
||||
Member of groups: ipausers, sysadmin
|
||||
Indirect Member of Sudo rule: sysadmin_sudo
|
||||
Indirect Member of HBAC rule: sysadmin_all
|
||||
Kerberos keys available: True
|
||||
SSH public key fingerprint: C4:62:89:7A:65:F9:82:12:EF:08:96:D1:C9:7D:51:A5 alice@ipademo.local
|
||||
(ssh-rsa)
|
||||
|
||||
During enrolment of the systems, SSSD has been configured to use
|
||||
FreeIPA as one of its identity domains and OpenSSH has been
|
||||
@ -99,16 +100,16 @@ Logging in to the server using SSH public key authentication should
|
||||
now work::
|
||||
|
||||
[alice@client]$ ssh -o GSSAPIAuthentication=no server.ipademo.local
|
||||
Enter passphrase for key '/home/alice/.ssh/id_rsa':
|
||||
Last login: Tue Feb 2 15:10:13 2016
|
||||
[alice@server]$
|
||||
|
||||
To verify the SSH public key was used for authentication, you can
|
||||
check the ``sshd`` service journal on the server, which should have
|
||||
an entry like::
|
||||
To verify that the SSH public key was used for authentication, you
|
||||
can check the ``sshd`` log on the server::
|
||||
|
||||
server.ipademo.local sshd[19729]: \
|
||||
Accepted publickey for alice from 192.168.33.20 port 37244 \
|
||||
ssh2: RSA SHA256:rgVSyPM/yn/b5bsZQIsAXWF+16zkP59VS9GS+k+bbOg
|
||||
[server]$ sudo journalctl -u sshd -S "5 minutes ago" --no-pager
|
||||
-- Logs begin at Mon 2018-06-04 19:01:11 UTC, end at Mon 2018-06-11 04:55:19 UTC. --
|
||||
Jun 11 04:51:52 server.ipademo.local sshd[8570]: Accepted publickey for alice from 192.168.33.20 port 57596 ssh2: RSA SHA256:KZ1MQCvaGAGZxKaMxmWBexzH98NPBsTsuo1uf/42SB0
|
||||
|
||||
|
||||
Using FreeIPA as a backend store for SSH host keys
|
||||
@ -120,8 +121,8 @@ key. The first time the host authenticates, the user may have to
|
||||
examine the target host's public key and manually authenticate it.
|
||||
The client then stores the host's public key in a ``known_hosts``
|
||||
file. On subsequent attempts to log in, the client checks its
|
||||
``known_hosts`` files and automatically grants access to recognised
|
||||
hosts.
|
||||
``known_hosts`` files. If the presented host key does not match the
|
||||
stored host key, the OpenSSH client refuses to continue.
|
||||
|
||||
Based on the last exercise, try to figure out how to upload SSH host
|
||||
keys to the FreeIPA server.
|
||||
|
||||
@ -40,16 +40,16 @@ proceed::
|
||||
|
||||
Continue to configure the system with these values? [no]: yes
|
||||
|
||||
You might see a warning about time synchronisation, which for this
|
||||
workshop can be ignored. Next you will be be prompted to enter
|
||||
credentials of a user authorised to enrol hosts (``admin``)::
|
||||
Next, the client's time will be synchronised with the server, then
|
||||
the installer will prompt you to enter the credentials of a user
|
||||
authorised to enrol hosts (``admin``)::
|
||||
|
||||
User authorized to enroll computers: admin
|
||||
Password for admin@IPADEMO.LOCAL:
|
||||
|
||||
The enrolment now proceeds; no further input is required. You will
|
||||
see output detailing the operations being completed. Unlike
|
||||
``ipa-server-install``, client enrolment only takes a few seconds.
|
||||
see output detailing the operations being completed. Client
|
||||
enrolment only takes a few seconds.
|
||||
|
||||
Users in your FreeIPA domain can now log into FreeIPA-enrolled
|
||||
hosts, subject to *Host-based access control* (HBAC) rules. Users
|
||||
|
||||
@ -49,14 +49,13 @@ commands starting with ``cert-``::
|
||||
cert-remove-hold cert-revoke cert-status
|
||||
|
||||
|
||||
You'll notice that commands are grouped by *plugin*. You can read a
|
||||
general overview of a plugin by running ``ipa help <plugin>``, and
|
||||
specific information on a particular command by running ``ipa help
|
||||
<command>``.
|
||||
You'll notice that commands are grouped by *topic*, or the kind of
|
||||
object they act upon. You can read a general overview of a plugin
|
||||
by running ``ipa help <topic>``, and specific information on a
|
||||
particular command by running ``ipa help <command>``.
|
||||
|
||||
Add a user named ``bob`` from the CLI. See if you can work out how
|
||||
to do this using the CLI help commands. (**hint**: the ``user``
|
||||
plugin provides the command).
|
||||
Add a user named ``bob`` from the CLI. Use the CLI help to find the
|
||||
right command (**hint**: the ``user`` plugin provides the command).
|
||||
|
||||
|
||||
User authentication
|
||||
@ -115,7 +114,7 @@ is a true *single sign-on* protocol!
|
||||
|
||||
[server]$ klist
|
||||
Ticket cache: KEYRING:persistent:1000:1000
|
||||
Default principal: admin@IPADEMO.LOCAL
|
||||
Default principal: bob@IPADEMO.LOCAL
|
||||
|
||||
Valid starting Expires Service principal
|
||||
06/04/2018 21:45:50 06/05/2018 21:38:24 host/client.ipademo.local@IPADEMO.LOCAL
|
||||
|
||||
15
4-hbac.rst
15
4-hbac.rst
@ -12,7 +12,7 @@ they are trying to access (or its *Host Groups*), and (optionally)
|
||||
the service being accessed.
|
||||
|
||||
In this unit, we will define an HBAC policy that restricts
|
||||
access to ``client.ipademo.local`` to members of the
|
||||
login access to ``client.ipademo.local`` to members of the
|
||||
``sysadmin`` user group.
|
||||
|
||||
|
||||
@ -26,9 +26,9 @@ UI or the ``ipa`` CLI program (don't forget to ``kinit admin``; see
|
||||
if you can work out what plugin provides the host group
|
||||
functionality).
|
||||
|
||||
**Hint:** if you use the CLI will need to run two commands - one to
|
||||
create the host group, and one to add ``client.ipademo.local`` as a
|
||||
member of the host group.
|
||||
**Hint:** if you use the CLI will need to run two separate
|
||||
commands—one to create the host group, then another to add
|
||||
``client.ipademo.local`` to the host group.
|
||||
|
||||
|
||||
Disabling the ``allow_all`` HBAC rule
|
||||
@ -118,7 +118,8 @@ command::
|
||||
Not matched rules: sysadmin_webservers
|
||||
|
||||
Poor ``bob``. He won't be allowed in because he is not a member of
|
||||
the ``sysadmin`` group. What about ``alice``?
|
||||
the ``sysadmin`` group. What is the result of ``ipa hbactest`` for
|
||||
``alice``?
|
||||
|
||||
``kinit`` as ``bob`` and try to log in to the client::
|
||||
|
||||
@ -127,7 +128,9 @@ the ``sysadmin`` group. What about ``alice``?
|
||||
[server]$ ssh bob@client.ipademo.local
|
||||
Connection closed by UNKNOWN port 65535
|
||||
|
||||
Then try ``alice``::
|
||||
The server refused to let ``bob`` in and closed the connection.
|
||||
|
||||
Now try ``alice``::
|
||||
|
||||
[server]$ kinit alice
|
||||
Password for alice@IPADEMO.LOCAL:
|
||||
|
||||
@ -14,7 +14,8 @@ authentication to authenticate users, PAM to enforce HBAC rules, and
|
||||
user attributes.
|
||||
|
||||
All activities in this unit take place on ``client`` unless
|
||||
otherwise specified.
|
||||
otherwise specified. **Access the host via ``vagrant ssh client``**
|
||||
to ensure you have ``sudo`` access.
|
||||
|
||||
The demo web application is trivial. It just reads its request
|
||||
environment and responds in plain text with a list of variables
|
||||
@ -36,8 +37,8 @@ Create a service
|
||||
Create a *service* representing the web application on
|
||||
``client.ipademo.local``. A service principal name has the service
|
||||
type as its first part, separated from the host name by a slash,
|
||||
e.g. ``HTTP/www.example.com``. The host part must correspond to an
|
||||
existing host in the directory.
|
||||
e.g. ``HTTP/www.example.com``. The host part must be a host
|
||||
enrolled in FreeIPA.
|
||||
|
||||
You must be getting the hang of FreeIPA by now, so I'll leave the
|
||||
rest of this step up to you. (It's OK to ask for help!)
|
||||
@ -50,8 +51,7 @@ The service needs access to its Kerberos key in order to
|
||||
authenticate users. Retrieve the key from the FreeIPA server and
|
||||
store it in a *keytab* file (you will need a TGT for ``admin``)::
|
||||
|
||||
[client]$ ipa-getkeytab -s server.ipademo.local \
|
||||
-p HTTP/client.ipademo.local -k app.keytab
|
||||
[client]$ ipa-getkeytab -p HTTP/client.ipademo.local -k app.keytab
|
||||
Keytab successfully retrieved and stored in: app.keytab
|
||||
|
||||
We also have to move the file, change its ownership and apply the
|
||||
@ -115,7 +115,7 @@ and make a request using ``curl``::
|
||||
REMOTE_PORT: 42499
|
||||
|
||||
The ``REMOTE_USER`` variable in the request environment indicates
|
||||
that there is a logged-in user and identifies that user.
|
||||
that there is an authenticated user, and identifies that user.
|
||||
|
||||
|
||||
Populating request environment with user attributes
|
||||
@ -128,8 +128,7 @@ attributes. In this section, we will use mod_lookup_identity_ to
|
||||
populate the HTTP request environment with variables providing
|
||||
information about the authenticated user.
|
||||
|
||||
.. _mod_lookup_identity: http://www.adelton.com/apache/mod_lookup_identity/
|
||||
|
||||
.. _mod_lookup_identity: https://www.adelton.com/apache/mod_lookup_identity/
|
||||
|
||||
``mod_lookup_identity`` retrieves user attributes from SSSD (via D-Bus).
|
||||
Edit ``/etc/sssd/sssd.conf``; enable the SSSD ``ifp`` *InfoPipe*
|
||||
@ -181,7 +180,7 @@ environment. The ``LookupUserXXX`` directives define the mapping of
|
||||
user attributes to request environment variables. Multi-valued
|
||||
attributes can be expanded into multiple variables, as in the
|
||||
``LookupUserGroupsIter`` directive. Do not forget the
|
||||
``LoadModule`` directive!
|
||||
``LoadModule`` directive at the top!
|
||||
|
||||
::
|
||||
|
||||
@ -207,7 +206,7 @@ attributes can be expanded into multiple variables, as in the
|
||||
</VirtualHost>
|
||||
|
||||
Default SELinux policy prevents Apache from communicating with SSSD
|
||||
over D-Bus. Flip ``httpd_dbus_sssd`` to ``1``::
|
||||
over D-Bus. Set ``httpd_dbus_sssd`` to ``1``::
|
||||
|
||||
[client]$ sudo setsebool -P httpd_dbus_sssd 1
|
||||
|
||||
|
||||
@ -4,54 +4,59 @@ Unit 6: Service certificates
|
||||
You probably noticed that the web service was not hosted over HTTPS,
|
||||
so there is no TLS-based authentication or confidentiality. In this
|
||||
unit, we will issue an X.509 certificate for the web service via
|
||||
the *certmonger* program.
|
||||
the *Certmonger* program.
|
||||
|
||||
Certmonger supports multiple CAs including FreeIPA's CA, and can
|
||||
generate keys, issue certifiate requests, track certificates, and
|
||||
renew tracked certificates when the expiration time approaches.
|
||||
Will also use ``mod_ssl`` with Apache.
|
||||
|
||||
Issue the service certificate
|
||||
-----------------------------
|
||||
|
||||
Let's start by confirming that the HTTP service does not yet have a
|
||||
certificate::
|
||||
|
||||
[client]$ ipa service-show HTTP/client.ipademo.local
|
||||
Principal: HTTP/client.ipademo.local@IPADEMO.LOCAL
|
||||
Principal name: HTTP/client.ipademo.local@IPADEMO.LOCAL
|
||||
Principal alias: HTTP/client.ipademo.local@IPADEMO.LOCAL
|
||||
Keytab: True
|
||||
Managed by: client.ipademo.local
|
||||
|
||||
Enable and start certmonger::
|
||||
Enable and start Certmonger::
|
||||
|
||||
[client]$ sudo systemctl enable certmonger
|
||||
Created symlink from /etc/systemd/system/multi-user.target.wants/certmonger.service to /usr/lib/systemd/system/certmonger.service.
|
||||
Created symlink /etc/systemd/system/multi-user.target.wants/certmonger.service → /usr/lib/systemd/system/certmonger.service.
|
||||
[client]$ sudo systemctl start certmonger
|
||||
|
||||
Now let's request a certificate. We will generate keys and store
|
||||
certificates in the NSS database at ``/etc/httpd/alias``::
|
||||
|
||||
[client]$ sudo ipa-getcert request -f /etc/pki/tls/certs/app.crt -k /etc/pki/tls/private/app.key \
|
||||
-K HTTP/client.ipademo.local \
|
||||
-D client.ipademo.local
|
||||
[client]$ sudo ipa-getcert request \
|
||||
-f /etc/pki/tls/certs/app.crt \
|
||||
-k /etc/pki/tls/private/app.key \
|
||||
-K HTTP/client.ipademo.local \
|
||||
-D client.ipademo.local
|
||||
New signing request "20180603185400" added.
|
||||
|
||||
Let's break down some of those command arguments.
|
||||
|
||||
``-k <path>``
|
||||
Path to private key
|
||||
Path to private key (Certmonger will generate it)
|
||||
``-f <path>``
|
||||
Path to certificate
|
||||
Path to certificate (where it will be saved after being issued)
|
||||
``-K <principal>``
|
||||
Kerberos service principal; because different kinds of services may
|
||||
be accessed at one hostname, this argument is needed to tell
|
||||
certmonger which service principal is the subject
|
||||
Kerberos service principal; because different kinds of services
|
||||
may be accessed at one hostname, this argument tells Certmonger
|
||||
which service principal is the subject
|
||||
``-D <dnsname>``
|
||||
Requests the given domain name to appear in the *Subject
|
||||
Alternative Name (SAN)* extension. The hostname will appear in
|
||||
the *Common Name (CN)* field but this practice is deprecated, so
|
||||
it is important to also include it in the SAN extension.
|
||||
Alternative Name (SAN)* extension; today the *Common Name (CN)*
|
||||
field is no longer used by browsers so the SAN value is essential
|
||||
|
||||
Another important argument is ``-N <subject-name>`` but this
|
||||
defaults to the system hostname, which in our case
|
||||
(``client.ipademo.local``) is appropriate.
|
||||
Another important option is ``-N <subject-name>``. It defaults to
|
||||
the system hostname, which in our case (``client.ipademo.local``) is
|
||||
appropriate.
|
||||
|
||||
Let's check the status of our certificate request using the tracking
|
||||
identifier given in the ``ipa-getcert request`` output::
|
||||
@ -77,13 +82,16 @@ identifier given in the ``ipa-getcert request`` output::
|
||||
auto-renew: yes
|
||||
|
||||
|
||||
Confirm that the certificate was issued and that certmonger is now
|
||||
Confirm that the certificate was issued and that Certmonger is now
|
||||
``MONITORING`` the certificate and will ``auto-renew`` it when it is
|
||||
close to expiration. Now if you run ``ipa service-show``, you will
|
||||
see a number of attributes related to the certificate, including the
|
||||
certificate itself. Can you work out how to save the PEM-encoded
|
||||
certificate to a file?
|
||||
|
||||
Set up TLS for Apache
|
||||
---------------------
|
||||
|
||||
Now we can reconfigure Apache to serve our app over TLS. Update
|
||||
``app.conf`` to listen on port 443 and add the SSL directives::
|
||||
|
||||
|
||||
@ -6,25 +6,29 @@ Unit 7: Replica installation
|
||||
- `Unit 1: Installing the FreeIPA server <1-server-install.rst>`_
|
||||
|
||||
FreeIPA is designed to be run in a replicated multi-master
|
||||
environment. In this unit, we will deploy a single FreeIPA
|
||||
replica. For recommended production topologies, see
|
||||
http://www.freeipa.org/page/Deployment_Recommendations#Replicas.
|
||||
environment. In this unit, we will install a replica of the
|
||||
existing master. For recommended production topologies, see
|
||||
https://www.freeipa.org/page/Deployment_Recommendations#Servers.2FReplicas.
|
||||
|
||||
If you have disabled the ``allow_all`` HBAC rule, add a new rule
|
||||
that will **allow ``admin`` to access the ``sshd`` service on any
|
||||
host**.
|
||||
|
||||
[To be confirmed] As of FreeIPA 4.3, replica installation is accomplished by
|
||||
*promoting* an enrolled client machine to a server.
|
||||
Client installation
|
||||
-------------------
|
||||
|
||||
SSH to the ``replica`` VM and enrol it per `Unit 2: Enrolling
|
||||
client machines`_.
|
||||
The first step of replica creation is to enrol the machine that will
|
||||
become the replica. SSH to the ``replica`` VM and enrol it per
|
||||
`Unit 2: Enrolling client machines <2-client-install.rst>`_
|
||||
|
||||
Replica promotion
|
||||
-----------------
|
||||
|
||||
Now promote the client to server. We will set up the replica
|
||||
*without* CA or DNS, but in a production deployment there should be
|
||||
at least one instance of these services in each datacentre. These
|
||||
components can be added later via ``ipa-ca-install(1)`` and
|
||||
``ipa-dns-install(1)``.
|
||||
*without* the CA or DNS role. In a production deployment there
|
||||
should be at least one instance of these services in each data
|
||||
centre. These roles can be configured later via
|
||||
``ipa-ca-install(1)`` and ``ipa-dns-install(1)``.
|
||||
|
||||
::
|
||||
|
||||
|
||||
@ -36,9 +36,11 @@ Observe that the action is denied::
|
||||
|
||||
[client]$ su -l alice
|
||||
Password:
|
||||
|
||||
[alice@client]$ sudo id
|
||||
[sudo] password for alice:
|
||||
alice is not allowed to run sudo on client. This incident will be reported.
|
||||
|
||||
[alice@client]$ exit
|
||||
logout
|
||||
|
||||
@ -75,6 +77,7 @@ Now attempt to ``sudo id`` as ``alice`` again::
|
||||
|
||||
[client]$ su -l alice
|
||||
Password:
|
||||
|
||||
[alice@client]$ sudo id
|
||||
[sudo] password for alice:
|
||||
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
|
||||
@ -82,6 +85,9 @@ Now attempt to ``sudo id`` as ``alice`` again::
|
||||
This time the action was allowed, and we can see from the output
|
||||
that ``alice`` indeed executed the ``id`` command as ``root``.
|
||||
|
||||
**Note:** if the command is prevented there may be some stale cache
|
||||
entries. Move on with the workshop and try again in 5 minutes.
|
||||
|
||||
|
||||
Permitting ``bob`` to run web administration commands
|
||||
-----------------------------------------------------
|
||||
@ -93,6 +99,7 @@ observe that ``bob`` currently cannot restart Apache::
|
||||
|
||||
[client]$ su -l bob
|
||||
Password:
|
||||
|
||||
[bob@client]$ sudo systemctl restart httpd
|
||||
[sudo] password for bob:
|
||||
Sorry, user bob is not allowed to execute '/bin/systemctl restart httpd' as root on client.ipademo.local.
|
||||
@ -115,7 +122,7 @@ Now define the ``webadmin_sudo`` rule. Note that we *do not* use
|
||||
Enabled: TRUE
|
||||
RunAs User category: all
|
||||
RunAs Group category: all
|
||||
[client]$
|
||||
|
||||
|
||||
Add the ``webadmin`` User Group and ``webservers`` Host Group to the rule::
|
||||
|
||||
@ -128,6 +135,7 @@ Add the ``webadmin`` User Group and ``webservers`` Host Group to the rule::
|
||||
-------------------------
|
||||
Number of members added 1
|
||||
-------------------------
|
||||
|
||||
[client]$ ipa sudorule-add-host webadmin_sudo --hostgroup webservers
|
||||
Rule name: webadmin_sudo
|
||||
Enabled: TRUE
|
||||
@ -147,16 +155,19 @@ web server administration::
|
||||
Added Sudo Command "/usr/bin/systemctl start httpd"
|
||||
---------------------------------------------------
|
||||
Sudo Command: /usr/bin/systemctl start httpd
|
||||
|
||||
[client]$ ipa sudocmd-add "/usr/bin/systemctl restart httpd"
|
||||
-----------------------------------------------------
|
||||
Added Sudo Command "/usr/bin/systemctl restart httpd"
|
||||
-----------------------------------------------------
|
||||
Sudo Command: /usr/bin/systemctl restart httpd
|
||||
|
||||
[client]$ ipa sudocmdgroup-add webadmin_cmds
|
||||
----------------------------------------
|
||||
Added Sudo Command Group "webadmin_cmds"
|
||||
----------------------------------------
|
||||
Sudo Command Group: webadmin_cmds
|
||||
|
||||
[client]$ ipa sudocmdgroup-add-member webadmin_cmds \
|
||||
--sudocmds "/usr/bin/systemctl start httpd" \
|
||||
--sudocmds "/usr/bin/systemctl restart httpd"
|
||||
@ -186,8 +197,10 @@ restart (or start) Apache, but not run other commands via ``sudo``::
|
||||
|
||||
[client]$ su -l bob
|
||||
Password:
|
||||
|
||||
[bob@client]$ sudo systemctl restart httpd
|
||||
[sudo] password for bob:
|
||||
|
||||
[bob@client]$ sudo id
|
||||
Sorry, user bob is not allowed to execute '/bin/id' as root on client.ipademo.local.
|
||||
|
||||
|
||||
@ -10,19 +10,20 @@ Unit 9: SELinux User Maps
|
||||
SELinux is a *mandatory access controls* mechanism for Linux,
|
||||
providing more powerful and flexible access control than traditional
|
||||
Unix permissions. Users have an SELinux *context* consisting of a
|
||||
*user*, *role* and *type*. The goal of this unit is to cause users
|
||||
*user*, *role* and *type*. In this unit, you will cause users
|
||||
to be *confined* by an SELinux *role-based access control (RBAC)*
|
||||
policy when the log into hosts that are members of the
|
||||
``webservers`` Host Group.
|
||||
|
||||
..
|
||||
- users can have different selinux policy on diff hosts
|
||||
``webservers`` Host Group. You will also learn how to change a
|
||||
user's SELinux context when they execute commands via Sudo.
|
||||
|
||||
**Note:** SELinux contexts are applied during PAM-based login, so
|
||||
when testing our changes in this unit ``su -l <user>`` will not
|
||||
suffice: it is necessary to log in via SSH. You can do this from
|
||||
any of the VMs (even ``client`` itself).
|
||||
|
||||
Confining users
|
||||
---------------
|
||||
|
||||
Log in as ``alice`` and run ``id -Z`` to see her current SELinux
|
||||
context::
|
||||
|
||||
@ -62,6 +63,7 @@ by the ``staff_u`` policy::
|
||||
[server]$ ssh alice@client.ipademo.local
|
||||
alice@client.ipademo.local's password:
|
||||
Last login: Fri Sep 2 05:47:03 2016
|
||||
|
||||
[alice@client]$ id -Z
|
||||
staff_u:staff_r:staff_t:s0-s0:c0.c1023
|
||||
|
||||
@ -83,15 +85,17 @@ inherit a user's context, as the following commands demonstrate::
|
||||
|
||||
[alice@client]$ sudo -s
|
||||
[sudo] password for alice:
|
||||
sh-4.3# id -Z
|
||||
staff_u:staff_r:staff_t:s0-s0:c0.c1023
|
||||
sh-4.3# systemctl restart httpd
|
||||
Failed to restart httpd.service: Access denied
|
||||
See system logs and 'systemctl status httpd.service' for details.
|
||||
sh-4.3#
|
||||
|
||||
Now let's make it so that ``alice`` can do her job. We need to
|
||||
update the Sudo rule to change the SELinux context::
|
||||
sh-4.4# id
|
||||
uid=0(root) gid=0(root) groups=0(root) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
|
||||
|
||||
sh-4.4# echo "Hello, world!" > /etc/motd
|
||||
sh: /etc/motd: Permission denied
|
||||
|
||||
As you can see, ``alice`` became ``root``, but the SELinux
|
||||
confinement prevents her from writing ``/etc/motd`` (and many other
|
||||
things). Let's make it so that ``alice`` can do her job. We need
|
||||
to update the Sudo rule to change the SELinux context::
|
||||
|
||||
[alice@client]$ ipa sudorule-add-option sysadmin_sudo --sudooption type=unconfined_t
|
||||
-------------------------------------------------------------
|
||||
@ -104,6 +108,7 @@ update the Sudo rule to change the SELinux context::
|
||||
RunAs User category: all
|
||||
RunAs Group category: all
|
||||
Sudo Option: type=unconfined_t
|
||||
|
||||
[alice@client]$ ipa sudorule-add-option sysadmin_sudo --sudooption role=unconfined_r
|
||||
-------------------------------------------------------------
|
||||
Added option "role=unconfined_r" to Sudo Rule "sysadmin_sudo"
|
||||
@ -120,11 +125,14 @@ Now when ``alice`` runs ``sudo`` it changes the SELinux context of
|
||||
the program being run::
|
||||
|
||||
[alice@client]$ sudo -s
|
||||
sh-4.3# id -Z
|
||||
staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
|
||||
sh-4.3# systemctl restart httpd
|
||||
sh-4.3#
|
||||
|
||||
sh-4.4# id -Z
|
||||
staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
|
||||
|
||||
sh-4.4# echo "Hello, world!" > /etc/motd
|
||||
|
||||
sh-4.4# cat /etc/motd
|
||||
Hello, world!
|
||||
|
||||
This concludes the unit. You can now proceed to
|
||||
`Unit 10: SSH user and host key management <10-ssh-key-management.rst>`_
|
||||
|
||||
16
workshop.rst
16
workshop.rst
@ -70,12 +70,10 @@ Preparation
|
||||
|
||||
Some preparation is needed prior to the workshop. The workshop is
|
||||
designed to be carried out in a Vagrant_ environment that configures
|
||||
three virtual machines with all software network configuration ready
|
||||
for the workshop.
|
||||
|
||||
several VMs. **The goal of the preparation** is to be able to
|
||||
successfully ``vagrant up`` the VMs as the first step of the
|
||||
workshop.
|
||||
three networked virtual machines (VMs) with all software needed for
|
||||
the workshop. **The goal of this preparation** is to ``vagrant up``
|
||||
the VMs. After this preparation is completed you are ready to begin
|
||||
the workshop.
|
||||
|
||||
.. _Vagrant: https://www.vagrantup.com/
|
||||
|
||||
@ -235,9 +233,9 @@ so it may not be feasible to download it during the workshop.
|
||||
Add hosts file entries
|
||||
----------------------
|
||||
|
||||
*This step is necessary if you want to access the FreeIPA Web UI in
|
||||
the VM from a browser on your host, but otherwise this step is optional. All
|
||||
workshop units can be completed using the CLI.*
|
||||
*This step is optional. All units can be completed using the CLI
|
||||
only. But if you want to access the FreeIPA Web UI or other web
|
||||
servers on the VMs from your browser, follow these instructions.*
|
||||
|
||||
Add the following entries to your hosts file::
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user