| 2021-07-20 08:26:48 |
Didier Roche-Tolomelli |
bug |
|
|
added bug |
| 2021-07-21 08:02:35 |
Didier Roche-Tolomelli |
bug |
|
|
added subscriber MIR approval team |
| 2021-07-27 14:59:29 |
Didier Roche-Tolomelli |
adsys (Ubuntu): assignee |
|
Matthias Klose (doko) |
|
| 2021-09-14 14:48:58 |
Christian Ehrhardt |
adsys (Ubuntu): assignee |
Matthias Klose (doko) |
Lukas Märdian (slyon) |
|
| 2021-09-15 09:26:51 |
Didier Roche-Tolomelli |
adsys (Ubuntu): assignee |
Lukas Märdian (slyon) |
Ubuntu Security Team (ubuntu-security) |
|
| 2021-09-15 09:28:23 |
Didier Roche-Tolomelli |
description |
[Availability]
Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted.
[Rationale]
We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies.
Right now, dconf keys are supported.
This feature is built and use the krb5 tickets which are provided by SSSD. Basically:
- SSSD is dealing with user and machine registration/authentification and enforce password policies
- ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon).
[Security]
The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user.
Polkit is used to restrain access to some part of the API.
There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded.
[Quality assurance]
Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO.
An extensive testsuite (more than 700) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure.
[Dependencies]
Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5.
This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them.
[Standards compliance]
Standard debhelper packaging, including a systemd service.
[Maintenance]
The desktop team will maintain it.
[Background information]
ADSys is composed of:
- a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated.
- a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service.
Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron.
The daemon contains a python embeeded script to reuse samba utilities to connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs are then downloaded in a cache directory which isn’t accessible to users.
The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped directly via the command line tool. Finally, those are automatically refreshed for any supported LTSes and intermediate versions. The availability of features can be different cross-release and is supported in the daemon.
Many utilities for debugging, following daemon or per transaction logs, streamed via our GRPC protocol are available.
We have different sync point with the system:
- at boot, the system will refresh the machine GPOs and build rules enforcements
- on login via the PAM module, which will:
a. download the machine GPOs if we couldn‘t before (due to no network available on boot/issues with NTP sync) and build rules enforcements
b. download the user-speciifc GPOs and build rules enforcements
- refresh every 30 minutes (same timing than windows client) the machine and all connected AD users GPOs, and rebuild rules enforcements if needed.
An offline mode (similar to SSSD) is available, so that you can carry your machine away of the network. The last successfully applied rules will still be enforced. Connection will be denied if you hadn’t connected once.
Documentation is available online (https://github.com/ubuntu/adsys/wiki) and also on the command line tool (offline). Note that updating the online documentation will update the command line tool one as an automated PR and updating the command line documentation will automatically update the wiki. |
[Availability]
Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted.
[Rationale]
We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies.
Right now, dconf keys are supported.
This feature is built and use the krb5 tickets which are provided by SSSD. Basically:
- SSSD is dealing with user and machine registration/authentification and enforce password policies
- ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon).
[Security]
The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user.
Polkit is used to restrain access to some part of the API.
There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded.
[Quality assurance]
Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO.
An extensive testsuite (more than 700) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure.
[Dependencies]
Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5.
This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them.
[Standards compliance]
Standard debhelper packaging, including a systemd service.
[Maintenance]
The desktop team will maintain it.
* we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included)
* we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary
* we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included)
* we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code
[Background information]
ADSys is composed of:
- a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated.
- a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service.
Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron.
The daemon contains a python embeeded script to reuse samba utilities to connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs are then downloaded in a cache directory which isn’t accessible to users.
The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped directly via the command line tool. Finally, those are automatically refreshed for any supported LTSes and intermediate versions. The availability of features can be different cross-release and is supported in the daemon.
Many utilities for debugging, following daemon or per transaction logs, streamed via our GRPC protocol are available.
We have different sync point with the system:
- at boot, the system will refresh the machine GPOs and build rules enforcements
- on login via the PAM module, which will:
a. download the machine GPOs if we couldn‘t before (due to no network available on boot/issues with NTP sync) and build rules enforcements
b. download the user-speciifc GPOs and build rules enforcements
- refresh every 30 minutes (same timing than windows client) the machine and all connected AD users GPOs, and rebuild rules enforcements if needed.
An offline mode (similar to SSSD) is available, so that you can carry your machine away of the network. The last successfully applied rules will still be enforced. Connection will be denied if you hadn’t connected once.
Documentation is available online (https://github.com/ubuntu/adsys/wiki) and also on the command line tool (offline). Note that updating the online documentation will update the command line tool one as an automated PR and updating the command line documentation will automatically update the wiki. |
|
| 2021-10-07 07:13:45 |
Jean-Baptiste Lallement |
bug |
|
|
added subscriber Jean-Baptiste Lallement |
| 2022-01-12 06:24:58 |
Christian Ehrhardt |
adsys (Ubuntu): importance |
Undecided |
Critical |
|
| 2022-01-12 06:25:00 |
Christian Ehrhardt |
adsys (Ubuntu): milestone |
|
ubuntu-20.04.4 |
|
| 2022-02-07 13:02:35 |
Jean-Baptiste Lallement |
description |
[Availability]
Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted.
[Rationale]
We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies.
Right now, dconf keys are supported.
This feature is built and use the krb5 tickets which are provided by SSSD. Basically:
- SSSD is dealing with user and machine registration/authentification and enforce password policies
- ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon).
[Security]
The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user.
Polkit is used to restrain access to some part of the API.
There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded.
[Quality assurance]
Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO.
An extensive testsuite (more than 700) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure.
[Dependencies]
Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5.
This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them.
[Standards compliance]
Standard debhelper packaging, including a systemd service.
[Maintenance]
The desktop team will maintain it.
* we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included)
* we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary
* we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included)
* we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code
[Background information]
ADSys is composed of:
- a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated.
- a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service.
Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron.
The daemon contains a python embeeded script to reuse samba utilities to connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs are then downloaded in a cache directory which isn’t accessible to users.
The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped directly via the command line tool. Finally, those are automatically refreshed for any supported LTSes and intermediate versions. The availability of features can be different cross-release and is supported in the daemon.
Many utilities for debugging, following daemon or per transaction logs, streamed via our GRPC protocol are available.
We have different sync point with the system:
- at boot, the system will refresh the machine GPOs and build rules enforcements
- on login via the PAM module, which will:
a. download the machine GPOs if we couldn‘t before (due to no network available on boot/issues with NTP sync) and build rules enforcements
b. download the user-speciifc GPOs and build rules enforcements
- refresh every 30 minutes (same timing than windows client) the machine and all connected AD users GPOs, and rebuild rules enforcements if needed.
An offline mode (similar to SSSD) is available, so that you can carry your machine away of the network. The last successfully applied rules will still be enforced. Connection will be denied if you hadn’t connected once.
Documentation is available online (https://github.com/ubuntu/adsys/wiki) and also on the command line tool (offline). Note that updating the online documentation will update the command line tool one as an automated PR and updating the command line documentation will automatically update the wiki. |
[Availability]
Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted.
[Rationale]
We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies.
Right now, dconf keys, sudo administration rights and computer and user scripts are supported.
This feature is built and use the krb5 tickets which are provided by SSSD. Basically:
- SSSD is dealing with user and machine registration/authentification and enforce password policies
- ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon).
[Security]
The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user.
Polkit is used to restrain access to some part of the API.
There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded.
[Quality assurance]
Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO.
An extensive testsuite (more than 1k) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure.
[Dependencies]
Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5.
This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them.
[Standards compliance]
Standard debhelper packaging, including a systemd service.
[Maintenance]
The desktop team will maintain it.
* we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included)
* we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary
* we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included)
* we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code
[Background information]
ADSys is composed of:
- a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated.
- a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service.
Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron.
The daemon contains a python embedded script that uses samba utilities to connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs are then downloaded in a cache directory which isn’t accessible to users.
The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped directly via the command line tool. Finally, those are automatically refreshed for any supported LTSes and intermediate versions. The availability of features can be different cross-release and is supported in the daemon.
Many utilities for debugging, following daemon or per transaction logs, streamed via our GRPC protocol are available.
We have different sync point with the system:
- at boot, the system will refresh the machine GPOs and build rules enforcements
- on login via the PAM module, which will:
a. download the machine GPOs if we couldn‘t before (due to no network available on boot/issues with NTP sync) and build rules enforcements
b. download the user-speciifc GPOs and build rules enforcements
- refresh every 30 minutes (same timing than windows client) the machine and all connected AD users GPOs, and rebuild rules enforcements if needed.
An offline mode (similar to SSSD) is available, so that you can carry your machine away of the network. The last successfully applied rules will still be enforced. Connection will be denied if you hadn’t connected once.
Documentation is available online (https://github.com/ubuntu/adsys/wiki) and also on the command line tool (offline). Note that updating the online documentation will update the command line tool one as an automated PR and updating the command line documentation will automatically update the wiki. |
|
| 2022-02-24 03:37:04 |
Seth Arnold |
bug watch added |
|
https://github.com/grpc/grpc-go/issues/5137 |
|
| 2022-02-24 03:37:04 |
Seth Arnold |
bug watch added |
|
https://github.com/olekukonko/tablewriter/issues/199 |
|
| 2022-02-24 03:37:11 |
Seth Arnold |
adsys (Ubuntu): status |
New |
In Progress |
|
| 2022-02-24 03:37:15 |
Seth Arnold |
adsys (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2022-03-21 14:40:21 |
Didier Roche-Tolomelli |
adsys (Ubuntu): status |
In Progress |
Fix Released |
|
