websms/freeipa
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Import Upstream version 4.12.4

Browse Source
This commit is contained in:
geos_one
2025-08-12 22:28:56 +02:00
parent 03a8170b15
commit 9181ee2487
1629 changed files with 874094 additions and 554378 deletions
Download Patch File Download Diff File Expand all files Collapse all files

159
doc/designs/adtrust/admin-ipa-as-trusted-user.md Normal file
View File

@@ -0,0 +1,159 @@
# Manage FreeIPA as a user from a trusted Active Directory domain
Allow users from trusted Active Directory forests to manage FreeIPA
resources if they are part of appropriate roles in FreeIPA. For example,
adding an Active Directory user as a member of 'admins' group would make
it equivalent to built-in FreeIPA 'admin' user.
The feature utilizes existing infrastructure for adding ID overrides of users
from trusted domains in the `Default Trust View`. User ID overrides in the
`Default Trust View` can only be created for the users from trusted Active
Directory forests. When Active Directory user authenticates with GSSAPI against
the FreeIPA LDAP server, its Kerberos principal is automatically mapped to the
user's ID override in the `Default Trust View`. LDAP server's access control
plugin uses membership information of the corresponding LDAP entry to decide
how access can be allowed.
## Use Cases
* As an Administrator in AD I want to also be able to fully administer FreeIPA
as if I am an FreeIPA admin so that I do not have to have two different
accounts and passwords.
* As an AD user I want to be able to use self service features of FreeIPA Web
UI for example to upload my SSH keys or change other related to me data that
is managed in FreeIPA on my behalf.
* As an AD user or Admin I want to be able to access FreeIPA Web UI with SSO if
I have a valid kerberos ticket
* As an AD user or Admin I want to be able to access FreeIPA Web UI and be
prompted for user name and password
* As an AD user who is assigned appropriate privileges in FreeIPA, I'd like to
be able enroll FreeIPA hosts.
* As an AD user who is assigned appropriate privileges in FreeIPA, I'd like to
be able to promote FreeIPA hosts to replicas.
* As an AD user who is assigned appropriate privileges in FreeIPA, I'd like to
be able to issue certificates for FreeIPA resources [not implemented].
## Design
### FreeIPA integration
FreeIPA allows to associate an ID override with an Active Directory
user. This user ID override stores information about user-specific POSIX
attributes: POSIX IDs for explicitly defined ID range case, home
directory, user's shell, SSH public keys, and associated user
certificates. ID overrides can be defined in a number of ID views, with
`Default Trust View` always applied by SSSD whenever information about
this AD user is requested in the FreeIPA realm.
Existence of the user ID override in the `Default Trust View` also
allows this user to bind to FreeIPA LDAP server when using GSSAPI
authentication. This is a feature that FreeIPA Web UI utilizes to
provide a web interfaces for a self-service of Active Directory users.
### Implementation
From the LDAP server perspective, FreeIPA access controls are based on the
membership in a certain group and role. If an LDAP object identity to which
authenticated LDAP bind is mapped belongs to a group or a role that allows
certain operations in the access controls, this identity is granted access
defined by the access controls.
Since user ID override is represented as a separate LDAP object in FreeIPA
LDAP store, its DN can be included into a group as a member. `memberof` plugin
requires to be able to add `memberof` attribute back to the entry that is added
as a member. As a result, ID override entry must include an object class that
allows this operation to succeed.
Thus, making ID override a group member in LDAP requires to expand existing set
of object classes in the ID override entry. There is standard object class in
389-ds, `nsmemberof`, that allows `memberof` attribute.
Another part of the requirement for members of groups in FreeIPA is to be able
to map a member DN back to its primary key for FreeIPA API purposes. This
requirement allows API to provide virtual attributes `member_<object>` that
contain primary keys of the members per each object type, to allow UI and CLI
to show them in a structured way.
For this to work, an object representing the group member has to provide an
implementation of the `LDAPObject.get_primary_key_from_dn()` method. For ID
overrides this method just needs to call existing
`resolve_anchor_to_object_name()` helper that performs SID or ipaUniqueID to
name transformation.
For Web UI operations, there is another requirement: group membership
management implementation requires lookup of an object by its primary key. In
case of ID overrides the overrides actually referred by a pair `<ID view, ID
override anchor>`. Since it is not possible to pass ID view detail, ID view is
set to be empty in those API calls. Since only Default Trust View is used for
mapping ID overrides to LDAP objects for authenticated LDAP binds, we can
default to `Default Trust View` in case the view is missing from the API call.
#### Web UI
In Web UI upon login there is a code that defines what view should be visible
for the user. This view already deals with Active Directory users and provides
them with a self-service view of their ID override entry in the `Default Trust
View`. With the proper support for the membership of ID overrides, ID override
entry now also return virtual attributes `memberof_group`, `memberofindirect_group`,
`memberof_role`, and `memberofindirect_role` that can be checked the same way
how membership is checked for normal IPA users.
### Access Control
389-ds LDAP server implements access control with the help of `acl` plugin.
This plugin relies on the membership information of the LDAP object of the
identity currenly bound to the LDAP server connection.
The `acl` plugin retrieves list of groups the bound LDAP object belongs to and
then evaluates each access based on the membership information and access
control lists (ACLs). Most if not all FreeIPA ACLs rely on the group membership
through the role/privilege/permission concepts.
If an active LDAP bound object belongs to certain groups and these groups
mentioned in the ACLs, this LDAP bound object will be allowed to perform those
LDAP operations which allowed through the ACLs.
### Upgrade and migration
The plugin does not require any schema updates because `nsMemberOf` is part of
the core 389-ds LDAP schema.
## Usage
In order to allow Active Directory user to manage FreeIPA, following steps
should be done:
* An ID override for the user should be created in the `Default Trust View`
* An ID override for the user should be added to an IPA group or directly to an
IPA role
* This group should be part of a role/privilege that allows
modification/management of any IPA object
### Sample usage
1. As admin, add ID override for a user (ad-user@ad.example.test):
```console
ipa idoverrideuser-add 'default trust view' ad-user@ad.example.test
```
2. Add ad-user\@ad.example.test to 'admins' group:
```console
ipa group-add-member admins --idoverrideusers ad-user@ad.example.test
```
3. Alternatively, the ID override can be added to a role:
```console
ipa role-add-member 'User Administrator' --idoverrideusers ad-user@ad.example.test
```
When ID override membership is removed from a group or a role, it will lose all
the power for any consequent authenticated LDAP session.

167
doc/designs/adtrust/auto-private-groups.md Normal file
View File

@@ -0,0 +1,167 @@
# ID Range: new option for private groups
## Description
SSSD provides an option to tune its behavior regarding private groups: *auto_private_groups*. Currently, this option is designed to work with **ldap** or **ad** providers and doesn’t behave properly when the provider is **ipa** and a trust is configured between IPA and AD.
The goal of this RFE is to propose the same setting at the trust level.
References:
* [BZ 1688267](https://bugzilla.redhat.com/show_bug.cgi?id=1688267) (ipa) [RFE] IPA to allow setting a new range type
* [BZ 1649464](https://bugzilla.redhat.com/show_bug.cgi?id=1649464) (sssd) auto_private_groups not working as expected with posix ipa/ad trust
* [SSSD #4216](https://github.com/SSSD/sssd/issues/4216) [RFC] IPA: allow switching off user private groups for trusted AD users
## High level overview
### Current auto private group behavior
The *auto_private_group* setting can be configured in the **DOMAIN** section of *sssd.conf*.
The *auto_private_groups* setting can take any of these 3 values:
* **true**: always create a user private group from the user’s UID number. If a GID number already exists, it is ignored.
* **false**: always use the users’ primary GID number. A group with this GID number must already exist.
* **hybrid**: a primary group is generated if the entry has UID = GID but there is no group with this GID. If UID and GID are different, a group with this GID number must already exist.
### Transposition to AD trust environments
#### Scope
When an IPA provider is used, with an AD trust, the UIDs and GIDs belong to different ID ranges:
* The users defined in IPA contain a uidNumber and gidNumber attribute, which must fit in the *ipa-local* range
* There are 2 possibilities for the users defined in AD:
* If they contain a uidNumber and gidNumber, the trust is established with a *ipa-ad-trust-posix* range and uidNumber and gidNumber values are taken from the user entry on AD
* If they don’t define uidNumber/gidNumber, the trust is established with a *ipa-ad-trust* range and SSSD computes uidNumber=gidNumber from the value of the user SID.
As there can be multiple ranges defined for a single ipa provider (for instance if multiple trusts are set), the *auto_private_groups* setting cannot have a domain scope and needs to be set at the **id range** level.
=> The setting needs to be added as an option to *ipa-ad-trust-posix* and *ipa-ad-trust* ranges.
#### Default behavior
When the *auto_private_groups* option is not explicitly set, it uses a default value:
* For *ipa-ad-trust-posix* range: default value = **false**. This means that the uidNumber and gidNumber of the AD entry are always used, and a group with the gidNumber must already exist.
* For *ipa-ad-trust* range: default value = **true**. This means that the uidNumber is mapped from the entry SID, the gidNumber is always set to the same value and a private group is always created.
### User stories
#### User story #1: AD trust with posix attributes, gidNumber corresponding to an existing group
As an administrator, I want to establish a trust between my IPA domain and my AD domain. My AD users contain posix attributes (uidNumber and gidNumber) that I want to use on IPA side, and the gidNumber corresponds to an existing AD group.
On any IPA client, the *id* command must return the uidNumber and gidNumber stored in AD:
```
# id aduser@AD-DOMAIN.COM
uid=uidNumber(aduser@ad-domain.com) gid=gidNumber(adgroup@ad-domain.com) groups=gidNumber(adgroup@ad-domain.com),...
```
If the gidNumber does not correspond to an existing group, the entry is not resolved.
#### User story #2: AD trust with posix attributes, gidNumber not corresponding to any group
As an administrator, I want to establish a trust between my IPA domain and my AD domain. My AD users contain posix attributes (uidNumber and gidNumber) but there is no group with the corresponding gidNumber.
On any IPA client, the id command must return the uidNumber stored in AD:
```
# id aduser@AD-DOMAIN.COM
uid=uidNumber(aduser@ad-domain.com) gid=uidNumber(aduser@ad-domain.com) groups=uidNumber(aduser@ad-domain.com),...
```
#### User story #3: AD trust with SID mapping, private group created with the uidNumber
As an administrator, I want to establish a trust between my IPA domain and my AD domain. My AD users are not posix, and their SID is mapped to an uidNumber and gidNumber on IPA. The gidNumber is equal to the uidNumber and a corresponding private group is generated.
On any IPA client, the id command must return the value computed from the SID stored in AD:
```
# id aduser@AD-DOMAIN.COM
uid=mappedValue(aduser@ad-domain.com) gid=mappedValue(aduser@ad-domain.com) groups=mappedValue(aduser@ad-domain.com),...
```
#### User story #4: AD trust with SID mapping, primary group reusing the primaryGroupID
As an administrator, I want to establish a trust between my IPA domain and my AD domain. My AD users are not posix, and their SID is mapped to an uidNumber on IPA. I want to compute the gidNumber from the RID of the AD entry’s primaryGroupID.
On any IPA client, the id command must return the value computed from the SID stored in AD:
```
# id aduser@AD-DOMAIN.COM
uid=mappedValue(aduser@ad-domain.com) gid=mappedValuePrimaryGroupID(adgroup@ad-domain.com) groups=mappedValuePrimaryGroupID(adgroup@ad-domain.com),...
```
#### Detailed behavior
##### ipa-ad-trust-posix
When the range has the *ipa-ad-trust-posix* type, the uidNumber and gidNumber are taken from the AD entry. Currently, if the gidNumber does not correspond to an existing group, the user cannot be resolved.
This situation can be fixed by setting
* *auto_private_groups=true*: a private group is created with gidNumber = uidNumber.
* *auto_private_group=hybrid*: if uidNumber=gidNumber but there is no group with this gidNumber, a private group is created with the gidNumber
auto_private_groups | true | false | hybrid
------------------- | ---- | ----- | ------
AD User entry with uidNumber=1000 gidNumber=missing | uid=1000 gid=1000 +private group | Not resolvable | Not resolvable
AD user entry with uidNumber=1000 gidNumber=2000 Group does not exist | uid=1000 gid=1000 +private group | Not resolvable | Not resolvable
AD User entry with uidNumber=1000 gidNumber=1000 Group does not exist | uid=1000 gid=1000 +private group | Not resolvable | uid=1000 gid=1000 +private group
AD User entry with uidNumber=1000 gidNumber=2000 Group exists | uid=1000 gid=1000 +private group | uid=1000 id=2000 | uid=1000 gid=2000
##### ipa-ad-trust
When the range has the *ipa-ad-trust* type, the uidNumber and gidNumber are computed from the entry’s SID. They currently both take the same value.
There are situations where the customer doesn’t want this behavior but would prefer to use the primaryGroupID set in the AD entry as gidNumber. This can be achieved by setting *auto_private_groups=false* and would solve the ticket [SSSD #4216](https://github.com/SSSD/sssd/issues/4216).
auto_private_groups | true | false | hybrid
------------------- | ---- | ----- | ------
AD User entry with SID mapped to 1000 primaryGroupID mapped to 2000 | uid=1000 gid=1000 +private group | uid=1000 gid=2000 | uid=1000 gid=2000
## Design
### IPA part
#### Schema
The LDAP schema for ID ranges needs to be modified:
* Creation of a new attribute to store the *autoprivategroups* option (with a DirectoryString type, single valued)
* Modification of the *ipaTrustedADDomainRange* objectclass in order to allow the new attribute as OPTIONAL
```
attributeTypes: (2.16.840.1.113730.3.8.23.6 NAME 'ipaAutoPrivateGroup' DESC 'Auto private groups' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v3' )
objectClasses: (2.16.840.1.113730.3.8.12.17 NAME 'ipaTrustedADDomainRange' SUP ipaIDrange STRUCTURAL MUST ( ipaBaseRID $ ipaNTTrustedDomainSID ) MAY ( ipaAutoPrivateGroup ) X-ORIGIN 'IPA v3' )
```
#### ID-range-related commands
*ipa idrange-add* and *ipa idrange-mod* need to provide a new option allowing to set *autoprivategroups* for the range if the range type is either *ipa-ad-trust* or *ipa-ad-trust-posix*.
*ipa idrange-find* will also allow to use *auto-private-groups* as a search criteria.
Note that *ipa-local* range should not accept the option.
```shell
# ipa idrange-add --help
[...]
--auto-private-groups=[‘true’, ‘false’, ‘hybrid’]
Automatic creation of private groups, one of allowed values.
[...]
# ipa idrange-mod --help
…
--auto-private-groups=[‘true’, ‘false’, ‘hybrid’]
Automatic creation of private groups, one of allowed values.
[...]
# ipa idrange-find --help
Usage: ipa [global-options] idrange-find [CRITERIA] [options]
[...]
--type=['ipa-ad-trust', 'ipa-ad-trust-posix', 'ipa-local']
ID range type, one of allowed values
[...]
```
*ipa idrange-show* must display the value, if any is set.
```shell
# ipa idrange-show AD-DOM.COM_id_range
[...]
Range name: AD-DOM.COM_id_range
First Posix ID of the range: 1136400000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-3005052257-2375221410-442149667
Range type: Active Directory domain range
Auto private groups: true
[...]
```
#### Trust establishment
*ipa trust-add* command also internally creates an idrange object but the decision is **NOT** to add new parameters for *auto-private-range* at this level. The rationale is that *ipa trust-add* currently provides only a subset of the idrange options (for instance it doesn’t allow to set *--rid-base*) and the finer configuration options are set using *ipa idrange-add* or *ipa idrange-mod*.
When the sysadmin wants to set *--auto-private-range*, he needs to do
* *ipa trust-add [options] AD-REALM*: this command also creates the idrange *AD-REALM_id_range*
* *ipa idrange-mod --auto-private-groups=value AD-REALM_id_range*
* and finally reset SSSD cache: *sss_cache -E*
#### Upgrade
There is no need to handle the new option during upgrade: SSSD must be able to assign a default value to *auto_private_groups* if none is set in the id range. The default value is picked according to the range type, in accordance with the content of sssd.conf man page:
* For *ipa-ad-trust-posix* range: default value = **false**.
* For *ipa-ad-trust* range: default value = **true**.
The schema upgrade does not require specific actions: the new attribute is optional in the existing object class and the schema is replicated to the other replicas in the topology as soon as one of them is upgraded with the new schema.

4
doc/designs/adtrust/samba-domain-controller.md
View File

@@ -173,7 +173,7 @@ As result of it, SMB attributes are not available at `ipa user-add` or
`ipa stageuser-add` level. Instead, it is possible to modify a user object with
`ipa user-mod` or `ipa stageuser-mod` commands:
```
```console
$ ipa user-mod --help
Usage: ipa [global-options] user-mod LOGIN [options]
@@ -216,7 +216,7 @@ By default, POSIX attribute can only be searched by LDAP clients in
Since SMB service belongs to `cn=services,cn=accounts,$basedn` subtree, new ACI
has to be added.
```
```python
'System: Read POSIX details of the SMB services': {
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'all',

30
doc/designs/adtrust/samba-domain-member.md
View File

@@ -142,14 +142,14 @@ Next steps should be performed on the client itself. With the support for Samba
domain member enabled, IPA masters allow creation of the required records with
the host credentials (`host/${hostname}`).
```
```console
# kinit -k
```
1. Retrieve information about Security Identifier and NetBIOS name of the IPA
domain:
```
```console
# kinit -k
# ipa trustconfig-show --raw
cn: ipa.realm
@@ -168,14 +168,14 @@ the host credentials (`host/${hostname}`).
: IPA domain's SID (security identifier)
`ipaflatname`
: IPA domain's NetBIOS name, `${netbios_name}, also known as the flat name in Active Directory
: IPA domain's NetBIOS name, `${netbios_name}`, also known as the flat name in Active Directory
`ipantdomainguid`
: IPA domain's globally unique identifier (GUID)
2. Retrieve ID range information for the IPA domain and other trusted domains:
```
```console
# ipa idrange-find --raw
----------------
2 ranges matched
@@ -203,7 +203,7 @@ the host credentials (`host/${hostname}`).
set for specific domains. For each such range, a pair of (range start, range
end) values will need to be calculated:
```
```ini
${range_id_min} = ipabaseid
${range_id_max} = ipabaseid + ipaidrangesize - 1
```
@@ -216,7 +216,7 @@ the host credentials (`host/${hostname}`).
a sequence of `ipa service-add` and `ipa service-mod` commands cannot be used
instead.
```
```console
# ipa service-add-smb <hostname> [<NetBIOS name>]
```
@@ -232,7 +232,7 @@ the host credentials (`host/${hostname}`).
enough for a machine account password. The code used by the
`ipa-client-samba` utility is equivalent for the following call:
```
```console
# python3 -c 'import samba; print(samba.generate_random_password(128, 255))'
```
@@ -244,7 +244,7 @@ the host credentials (`host/${hostname}`).
to [MS-NRPC] section 3.1.4.3.1. The code used by the `ipa-client-samba`
utility is equivalent for the following call:
```
```console
# ipa-getkeytab -p cifs/<hostname> -k /etc/samba/samba.keytab -P \
-e aes128-cts-hmac-sha1-96,aes256-cts-hmac-sha1-96,arcfour-hmac
```
@@ -260,7 +260,7 @@ the host credentials (`host/${hostname}`).
6. Create Samba config as `/etc/samba/smb.conf` on the client:
```
```ini
[global]
# Limit number of forked processes to avoid SMBLoris attack
max smbd processes = 1000
@@ -309,7 +309,7 @@ the host credentials (`host/${hostname}`).
that the POSIX path specified in the share actually allows write access to
the users or groups from the `write list`:
```
```ini
[shared]
path = /srv/shared
read only = No
@@ -327,7 +327,7 @@ the host credentials (`host/${hostname}`).
`smb.conf`. Instead, it is stored in the binary databases managed by Samba.
It can be set through `net setdomainsid` command:
```
```console
# net setdomainsid ${ipantsecurityidentifier}
```
@@ -335,7 +335,7 @@ the host credentials (`host/${hostname}`).
POSIX groups. It is typically mapped to a local nobody group. This is
required in all recent Samba releases:
```
```console
# net groupmap add sid=S-1-5-32-546 unixgroup=nobody type=builtin
```
@@ -351,7 +351,7 @@ the host credentials (`host/${hostname}`).
procedure has to be used. The procedure employs low-level tools to
manipulate Samba TDB databases:
```
```console
# tdbtool /var/lib/samba/private/secrets.tdb store SECRETS/MACHINE_LAST_CHANGE_TIME/${netbios_name} '2\00'
# tdbtool /var/lib/samba/private/secrets.tdb store SECRETS/MACHINE_PASSWORD/${netbios_name} '2\00'
# net changesecretpw -f
@@ -366,7 +366,7 @@ the host credentials (`host/${hostname}`).
all fallback code for the cases when `winbindd` was not running in some
configurations was removed from `smbd` daemon in newer Samba releases.
```
```console
# systemctl start smb winbind
```
@@ -378,7 +378,7 @@ started, one can access a Samba share as a user from IPA domain. Below is an
example from the test run of `ipatests/test_integration/test_smb.py` done by PR
CI.
```
```console
# kinit athena
Password for athena@IPA.TEST:
# mkdir -p /mnt/athena

301
doc/designs/adtrust/sidconfig.md Normal file
View File

@@ -0,0 +1,301 @@
# Integrate SID configuration into base IPA installers
## Overview
FreeIPA is able to issue Kerberos tickets with PAC data when it is configured
for trust. The goal of this feature is to allow PAC generation in the
general use case, even without trust, as it is a first step towards
IPA-IPA trust.
Reference: https://pagure.io/freeipa/issue/8995
In order to generate PAC data for a kerberos principal, IPA needs to assign
a SID to the users and groups. IPA installers (`ipa-server-install`,
`ipa-replica-install`) must handle the configuration related to SID:
- assign a NetBIOS name to the server
- assign a domain SID to the IPA domain
- configure the local id range with primary RID base and secondary RID base
- enable the sidgen plugin on 389ds server
The code handling these steps is already available in ipa-adtrust-install
and needs to be moved to the general installers.
## Use Cases
### Fresh install
As administrator, I want to deploy an IPA topology that automatically
assigns SIDs to users and groups and issues kerberos tickets with PAC data,
without the need to configure IPA for trust.
If I later decide to configure IPA for trust, I can still run the command
`ipa-adtrust-install`.
### Existing installation, no trust
As IPA administrator, I am managing an existing IPA installation without any
trust. I want to update IPA and have the choice of enabling (or not) the
generation of SIDs and PAC data.
If I choose to enable PAC data, I just need to run a command that requires
an admin kerberos ticket. The command handles the SID-related configuration
and prompts me whether I want to immediately generate SIDs for
existing users/groups or run that task later.
### Existing installation, trust configured
In this topology with trust configured (the command `ipa-adtrust-install` has
been executed), IPA is already able to issue Kerberos tickets with PAC data.
Update does not modify the configuration.
### Mixed topology
As IPA administrator, I am managing an existing server setup without trust and
without PAC data. I want to add a replica into my existing topology and
automatically enable PAC data generation, without the need to configure IPA
for trust.
## How to Use
### Fresh installation
Run `ipa-server-install`, with the ability to define:
- NetBIOS Name: if not specified, the default value is generated from
the IPA domain name (transform the left-most label into uppercase, keep only
ascii characters, digits and dashes).
- Primary RID base (default if not set: 1000)
- Secondary RID base (default if not set: 1000000)
On a replica: run `ipa-replica-install`, with the ability to define the same
parameters as `ipa-server-install`, plus the following parameter:
- Run SIDgen task immediately: yes/no (default=no)
If conflicting values are specified in `ipa-replica-install`, the installer
must warn that existing values will be overwritten (same message as when
`ipa-adtrust-install` is run multiple times with conflicting values).
### Upgrade
- Run `dnf update *ipa-server`. The upgrade doesn't configure SID-related
options and doesn't enable PAC generation.
- Obtain a ticket for the admin (or any member of the admins group).
- Run the new command allowing to setup the SID-related configuration.
- Run the existing command to modify base RID and secondary base RID:
```
ipa idrange-mod --rid-base INT --secondary-rid-base INT RANGENAME
```
### Mixed topology
The existing server is not setup for PAC data generation. The future replica
is installed with the latest packages, containing the updated installers.
Run `ipa-replica-install`, with the ability to define:
- NetBIOS Name: if not specified, the default value is generated from
the IPA domain name (transform the left-most label into uppercase, keep only
ascii characters, digits and dashes).
- Primary RID base (default if not set: 1000)
- Secondary RID base (default if not set: 1000000)
- Run SIDgen task immediately: yes/no (default=no)
## Design
Installers and SID-related options:
- the options `--add-sids`, `--netbios-name`, `--rid-base` and
`--secondary-rid-base` are moved from ADTrustInstallInterface to a separate
new InstallInterface: SIDInstallInterface.
- ADTrustInstallInterface now inherits from SIDInstallInterface.
- `adtrustinstance.ADTRUSTInstance.__init__` now accepts an additional
parameter: `fulltrust`. When set to True, the class ADTRUSTInstance configures
the trust as usual. When set to False, only the SID-related part is executed.
- `ipa-server-install` and `ipa-replica-install` now always call
`adtrust.install_check` and `adtrust.install`, but the method is using the
provided options (especially `options.setup_adtrust`) to know if full
configuration is required or only the SID-related part.
The `ipa-adtrust-install` code is already written in order to be
idempotent (can be called multiple times, even with different values), and
this property is of great value for this feature. It allows to keep
the changes as minimal as possible to the existing installers, and
call `ipa-adtrust-install` even if the SID-part is already setup.
New command to enable SID generation after an upgrade:
as we don't want to automatically enable SID generation during an upgrade,
a new command is provided in order to manually enable the feature. The command
only requires an admin ticket (no need to be root) and relies on the admin
framework.
The command uses a mechanism similar to server_conncheck:
- the user must have Replication Administrators privilege
- the user launches an ipa command communicating with IPA framework
- the admin framework uses Dbus to get access a DBus interface that
launches a command through oddjob, allowing the command to run as root.
The oddjob command is a wrapper around `adtrustinstance.ADTRUSTInstance`.
## Implementation
- Dependencies: no additional dependency on ipa-server package
- Backup and Restore: no new file to backup
## Feature Management
### UI
No new UI for server/replica installation.
`IPA server / ID ranges` tab is already available and displays Primary and
Secondary RID base.
`IPA Server / Trusts / Global Trust Configuration` tab already displays the
NetBIOS Name and Security Identifier.
These values can also be added in the `IPA Server / Configuration` tab.
The User View displays SMB attributes if they exist and could be enhanced
with a note if the user entry does not have any SID, pointing the admin
to a procedure in order to generate the missing SIDs.
### CLI
| Command | Options |
| --- | ----- |
| ipa-server-install | [--netbios-name=NETBIOS_NAME] [--rid-base=RID_BASE] [--secondary-rid-base=SECONDARY_RID_BASE] |
| ipa-replica-install | [--netbios-name=NETBIOS_NAME] [--rid-base=RID_BASE] [--secondary-rid-base=SECONDARY_RID_BASE] [--add-sids] |
| ipa config-mod | --enable-sid [--add-sids] [--netbios-name=NETBIOS_NAME] |
#### `ipa config-mod --enable-sid` details:
The `--enable-sid` option turns the feature on, and `--add-sids` triggers
the SIDgen task in order to immediately generate SID for existing users or
groups.
`--add-sids` requires the `--enable-sid`option.
The `--netbios-name` option specifies the NetBIOS Name and is optional. If
not provided, the NetBIOS Name is generated from the leading part of the
DNS name.
`--netbios-name` requires the `--enable-sid` option.
### Configuration
When the feature is turned on, it is possible to modify the primary and
secondary RID bases for the local id range with the existing
`ipa idrange-mod` command.
The NetBIOS Name can be overwritten (with warning) when `ipa-adtrust-install`
is run.
## Upgrade
The upgrade does not turn on the feature. If the admin wants to enable
SID generation, he needs to update the packages and run the new command
`ipa config-mod --enable-sid`.
## Test plan
Note: PRCI currently doesn't have the ability to test upgrade.
Scenarios to be tested: fresh install, test PAC generation
- Add active user testuser (reinitialize password)
- On IPA server run `kinit -k` to get a ticket for `host/fqdn@REALM`
- On IPA server run `/usr/libexec/ipa/ipa-print-pac ticket testuser` and
ensure that PAC data is properly displayed.
- Same test on IPA replica
Tests outside of PRCI:
- Existing topology without trust, update one server, ensure SID generation
hasn't been automatically enabled
- Existing topology without trust, update one server, manually enable SID
generation with the new command
- Existing topology without trust, insert a new replica, ensure SID generation
has been automatically enabled
- Existing topology with trust, update one server, ensure SID generation is
still working
- Existing topology with trust, insert a new replica, ensure SID generation
is still working
- Ensure that `ipa-adtrust-install` is still working with the previous
scenarios.
## Troubleshooting and debugging
When the feature is turned on (whatever the path, either through fresh
server installation, fresh replica installation, or with the new command), the
following LDAP entries are expected:
- `cn=ad,cn=trusts,dc=ipa,dc=test` which is a simple `nsContainer`
- `cn=ad,cn=etc,dc=ipa,dc=test` which is a simple `nsContainer`
- `cn=ipa.test,cn=ad,cn=etc,dc=ipa,dc=test`: must define the NetBIOS Name in
`ipaNTFlatName`, the SID in `ipaNTSecurityIdentifier` and the default SMB
group in `ipaNTFallbackPrimaryGroup`
- `cn=Default SMB Group,cn=groups,cn=accounts,dc=ipa,dc=test`: must define
a SID belonging to the IPA domain SID in `ipaNTSecurityIdentifier`
(replace ipa.test with the actual domain name and dc=ipa,dc=test with the
actual base DN).
The admin user must have a SID ending with -500 (well-known SID for the
domain administrator):
```
# ipa user-show admin --all | grep ipantsecurityidentifier
ipantsecurityidentifier: S-1-5-21-2633809701-976279387-419745629-500
```
The admins group must have a SID ending with -512 (well-known SID for domain
administrators group):
```
# ipa group-show admins --all | grep ipantsecurityidentifier
ipantsecurityidentifier: S-1-5-21-2633809701-976279387-419745629-512
```
The sidgen plugin must be enabled in /etc/dirsrv/slapd-IPA-TEST/dse.ldif:
```
dn: cn=IPA SIDGEN,cn=plugins,cn=config
cn: IPA SIDGEN
nsslapd-basedn: dc=ipa,dc=test
nsslapd-plugin-depends-on-type: database
nsslapd-pluginDescription: Add a SID to newly added or modified objects with u
id pr gid numbers
nsslapd-pluginEnabled: on
nsslapd-pluginId: IPA SIDGEN postop plugin
nsslapd-pluginInitfunc: ipa_sidgen_init
nsslapd-pluginPath: libipa_sidgen
nsslapd-pluginType: postoperation
nsslapd-pluginVendor: FreeIPA project
nsslapd-pluginVersion: FreeIPA/1.0
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
```
If the PAC data is not generated for a user, ensure that the user contains a
SID in its `ipantsecurityidentifier` attribute. If the SID is missing, run
the SIDgen task in order to generate SID for existing users and groups:
- Find ipa base DN with: `grep basedn /etc/ipa/default.conf | cut -d= -f2-`
- Copy `/usr/share/ipa/ipa-sidgen-task-run.ldif` to
`/tmp/ipa-sidgen-task-run.ldif`
- Edit the copy `/tmp/ipa-sidgen-task-run.ldif` and replace $SUFFIX with
IPA base DN
- As root, launch the task (replace IPA-TEST with the proper value):
`ldapmodify -H ldapi://%2Frun%2Fslapd-IPA-TEST.socket -f /tmp/ipa-sidgen-task-run.ldif`
In order to check if the PAC data gets added to the user ticket, on a server:
```
# kinit -k
# /usr/libexec/ipa/ipa-print-pac ticket USERNAME
```
If the PAC data is properly added, the `ipa-print-pac` command displays:
```
# /usr/libexec/ipa/ipa-print-pac ticket testuser
Password:
Acquired credentials for testuser
PAC_DATA: struct PAC_DATA
num_buffers : 0x00000005 (5)
version : 0x00000000 (0)
buffers: ARRAY(5)
buffers: struct PAC_BUFFER
...
```

207
doc/designs/adtrust/sudorules-with-ad-objects.md Normal file
View File

@@ -0,0 +1,207 @@
# Include users and groups from a trusted Active Directory domain into SUDO rules
Allow users and groups from trusted Active Directory forests to be directly
added to SUDO rules.
## Use Cases
* As an FreeIPA administrator, I want to add AD users and groups directly to SUDO
rules without creating an indirect POSIX group membership for them.
## Design
### FreeIPA integration
FreeIPA manages and stores SUDO rules in LDAP and SSSD retrieves the rules
related to the specific host it runs on. The rules are then provided to SUDO
via a special SUDOERS plugin which is talking to SSSD.
SUDOERS allows multiple ways of expressing users and groups as a part of the rule.
According to the SUDOERS manual page, the following syntax is supported:
```console
User ::= '!'* user name |
'!'* #uid |
'!'* %group |
'!'* %#gid |
'!'* +netgroup |
'!'* %:nonunix_group |
'!'* %:#nonunix_gid |
'!'* User_Alias
```
> A `User_List` is made up of one or more user names, user-IDs (prefixed with ‘#’),
> system group names and IDs (prefixed with `%` and `%#` respectively), netgroups
> (prefixed with ‘+’), non-Unix group names and IDs (prefixed with `%:` and `%:#`
> respectively) and `User_Aliases`. Each list item may be prefixed with zero or
> more `!` operators. An odd number of `!` operators negate the value of the
> item; an even number just cancel each other out. User netgroups are matched
> using the user and domain members only; the host member is not used when
> matching.
As can be seen from the SUDOERs definition of a `User`, any object that maps
into a user or a group is allowed. LDAP schema used to model SUDO rules in
FreeIPA does require SUDO `User` references to be real LDAP objects. In order
to support non-LDAP objects both FreeIPA and SSSD support a special attribute
`externalUser`. `externalUser` is a string that is merged with other `User`
references at SSSD side.
SSSD already supports querying with first five forms. When SUDO rules are
retrieved from FreeIPA, the references for groups are converted to `%group`
format in SSSD database. Correspondingly, ID-based forms (`#uid` and `%#gid`)
are added as well. It does not, however, support queries for non-Unix group
names and IDs.
SSSD team decided to not support `%:nonunix_group` and `%:nonunix_gid` syntax.
Without changes on SSSD side it will be not possible to support them.
Since in FreeIPA environment all AD users and groups resolvable by SSSD will
have POSIX attributes, they can be queried with the first four name forms.
### Implementation
FreeIPA framework's LDAP abstraction layer allows to validate and transform
membership information when members are added to 'group' objects or removed
from them. SUDO rules represent one such 'group' object.
LDAP abstraction layer provides `add_external_pre_callback()` method that
allows to redefine validators used to validate member names. Originally this
was done to allow hostname validation and reused default validators associated
with a parameter type associated with a specific parameter.
We extend `add_external_pre_callback()` to provide per-object validator
callbacks.
Validator callbacks can be extended to allow a fine grained validation
strategy. This is helpful to apply an alternative validation strategy in the
case a default validator fails.
New validators can be added to `member_validator` registry in a similar
way to how API objects are registered:
```python
from .baseldap import member_validator
@member_validator(membertype='foo')
def my_new_validator(ldap, dn, keys, options, value):
<validate value here>
```
Arguments passed to the validator are arguments passed to the
`add_external_pre_callback()` augmented with the value to validate.
This approach provides a general method to extend validation mechanism for any
parameter. The feature utilizes existing infrastructure for resolving objects
from trusted Active Directory forests provided by ID views plugin. Any user or
group from a trusted Active Directory domain can be resolved in the validator
and mapped to a user or group member type for SUDO rule inclusion.
Since `options` dictionary is the only object shared between the caller to
`add_external_pre_callback()` and the member type validator, ID views' member
type validator returns all validated values as a list stored as a
`trusted_objects` element of the `options` dictionary.
SUDO rule plugin implementation then processes the translated trusted object
members reported after calling the `add_external_pre_callback()`. Each
translated member is the one not found in LDAP as a direct reference and found
in a trusted domain. All these members are then added to `externalUser`
attribute.
Note that direct manipulation of `externalUser` attribute through IPA
parameters is not allowed since 2011 (FreeIPA tickets
https://pagure.io/freeipa/issue/1320). With membership validation method SUDO
rules can now handle those members through the normal `--users` mechanism.
Same approach is used to provide handling of `RunAs_Member` specification
which is mapped to either `ipaSudoRunAsExtUser` or `ipaSudoRunAsExtGroup`.
#### Web UI
Web UI already allows to specify external users and groups in SUDO rules. Names
provided by the user weren't validated, now they are verified to belong to
trusted domains.
### Upgrade and migration
The changes to plugins do not require any schema updates because there are no
LDAP schema changes.
## Usage
In order to add an Active Directory user to a SUDO rule, there must be a trust
established to the Active Directory forest where a domain of the user is
located. Any modification of SUDO rules with Active Directory users and groups
should happen on Trust Controllers or Trust Agents because other IPA replica
types are unable to validate AD users and group.
### Sample usage
Below example shows a generic usage of SUDO rules with AD users. It assumes we
want to allow an Active Directory user(s) ability to operate on all hosts and
all commands without authentication. In real life it is not recommended to
grant so wide access.
1. As admin, create an HBAC rule to permit all users to run SUDO on all hosts:
```console
ipa hbacrule-add hbacrule --usercat=all --hostcat=all
ipa hbacrule-add-service hbacrule --hbacsvcs=sudo
```
2. As an admin, create SUDO rule that allows to run all commands on all hosts:
```console
ipa sudocmd-add ALL
ipa sudorule-add sudorule --hostcat=all
ipa sudorule-add-option sudorule --sudooption '!authenticate'
ipa sudorule-add-allow-command sudorule --sudocmds ALL
```
2. Add `ad-user\@ad.example.test` to the SUDO rule:
```console
ipa sudorule-add-user sudorule --users ad-user@ad.example.test
```
3. Alternatively, add an Active Directory group `somegroup@ad.example.test` to the SUDO rule:
```console
ipa sudorule-add-user sudorule --groups 'somegroup@ad.example.test'
```
4. On an IPA-enrolled client, perform SUDO access as an Active Directory user:
```console
# su - ad-user@ad.example.test -c 'sudo -l'
Matching Defaults entries for ad-user@ad.example.test on client:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User ad-user@ad.example.test may run the following commands on master:
(root) NOPASSWD: ALL
```
5. To limit rule execution to a specific user and/or group, `runAsUser` and
`runAsGroup` properties can be set individually:
```console
ipa sudorule-add-runasuser sudorule --users 'ad-user@ad.example.test'
ipa sudorule-add-runasgroup sudorule --groups 'somegroup@ad.example.test'
```
6. The limits will be reflected in `sudo -l` output:
```console
# su - ad-user@ad.example.test -c 'sudo -l'
Matching Defaults entries for ad-user@ad.example.test on client:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User ad-user@ad.example.test may run the following commands on master:
(ad-user@ad.example.test : "%somegroup@ad.example.test") NOPASSWD: ALL
```