ubuntu
Issue: adsys selects Global Catalog from wrong domain when --objectclass is user in multi-domain environment
Is there an existing issue for this?
- [x] I have searched the existing issues and found none that matched mine
Describe the issue
Hello, I'm out of ideas. We have a forest and two domains: one for the users and one for the computers. Each has its own GPOs.
I want to use adsys to apply the GPOs, but when a user tries to log in, the client fetches the client GPOs but not the user GPOs. I get the following error:
ERROR Error from server: error while updating policy: can't get policies for "[email protected]": failed to retrieve the list of GPO (exited with 1): exit status 1
I edited the adsys-gpolist (adsys) to manually set the FQDN for --objectclass user:
if args.objectclass == ObjectClass.user:
fqdn = '<*RODC*.user.domain>
With this, I can retrieve the user GPOs (and also the client GPOs). From what I understand, adsys gets the Global Catalog (GC) server from sssd. But the issue is: when I run sssctl domain-status computer.domain, I get all of our AD servers, because all of them are GC servers:
Online status: Offline
Active servers:
AD Global Catalog: *RODC*.computer.domain
AD Domain Controller: *RODC*.computer.domain
Discovered AD Global Catalog servers:
- *RODC*.computer.domain
- *RODC*.computer.domain
- *RODC*.user.domain
- *RODC*.user.domain
- *dc*.computer.domain
- *dc*.computer.domain
- *dc*.user.domain
- *dc*.user.domain
And when I run sssctl domain-status user.domain, I get the same servers – with one difference: the AD Domain Controller is from the correct domain (user.domain), but the Global Catalog is still from computer.domain.
Online status: Online
Active servers:
AD Domain Controller: *RODC*.user.domain
AD Global Catalog: *RODC*.computer.domain
Discovered AD Global Catalog servers:
- *RODC*.computer.domain
- *RODC*.computer.domain
- *RODC*.user.domain
- *RODC*.user.domain
- *dc*.computer.domain
- *dc*.computer.domain
- *dc*.user.domain
- *dc*.user.domain
So adsys is picking the wrong GC when --objectclass is user.
I tried different sssd.conf setups, using only one domain or setup user.domain also, but nothing changed the error – and I'm out of ideas. I need help. This is my current sssd.conf:
[sssd]
services = nss, pam, pac
domains = computer.domain
default_domain_suffix = user.domain
config_file_version = 2
#debug_level = 5
[domain/computer.domain]
id_provider = ad
access_provider = ad
ad_domain = computer.domain
krb5_realm = COMPUTER.DOMAIN
#ad_server = *dc*.computer.domain
#ldap_uri = ldap://*dc*.computer.domain/
ldap_referrals = false
ldap_id_mapping = true
krb5_keytab = /etc/krb5.keytab
ad_gpo_access_control = enforcing
#ad_allow_remote_domain_local_groups = true
And my krb5.conf:
[libdefaults]
default_realm = COMPUTER.DOMAIN
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
udp_preference_limit = 0
[domain_realm]
.computer.domain = COMPUTER.DOMAIN
.user.domain = USER.DOMAIN
and the log from adsys when i tried to login:
login <user>
Passwort:
Applying machine settings
DEBUG Connecting as [[33207:810689]]
DEBUG New request /service/UpdatePolicy
DEBUG Requesting with parameters: IsComputer: true, All: false, Target: ubuntu24-kde, Krb5Cc: , Purge: false
DEBUG NormalizeTargetName for "ubuntu24-kde", type "computer"
DEBUG Check if grpc request peer is authorized
DEBUG Authorized as being administrator
DEBUG GetPolicies for "ubuntu24-kde", type "computer"
DEBUG Triggering autodiscovery of AD server triggered because sssd.conf does not provide an ad_server for "computer.domain"
DEBUG Getting gpo list with arguments: "--objectclass computer *RODC*.computer.domain ubuntu24-kde"
DEBUG GPO "AD - Client - Linux GDM Sperrbildschirm (Test) - C" for "ubuntu24-kde" available at "smb://*RODC*.computer.domain/SysVol/computer.domain/Policies/{899A00AE-FE17-4AC2-992F-6304AADD17AA}"
DEBUG GPO "AD - Client - Linux User Favorisierte Apps auf dem Desktop (Test) - C" for "ubuntu24-kde" available at "smb://*RODC*.computer.domain/SysVol/computer.domain/Policies/{AB59982C-E31B-4DC5-8446-306D6589FE77}"
[...]
DEBUG Analyzing "******"
[...]
INFO No assets directory with GPT.INI file found on AD, skipping assets download
[...]
INFO GPO "****" is already up to date
[...]
DEBUG Parsing GPO "AD - Client - Linux GDM Sperrbildschirm (Test) - C" of class "computer"
DEBUG Found registry policy file "/var/cache/adsys/sysvol/Policies/{899A00AE-FE17-4AC2-992F-6304AADD17AA}/Machine/Registry.pol"
DEBUG Parsing GPO "AD - Client - Linux User Favorisierte Apps auf dem Desktop (Test) - C" of class "computer"
DEBUG Policy directory "/var/cache/adsys/sysvol/Policies/{AB59982C-E31B-4DC5-8446-306D6589FE77}/MACHINE" not found
DEBUG Policy "AD - Client - Linux User Favorisierte Apps auf dem Desktop (Test) - C" doesn't have any policy for class "computer"
[...]
DEBUG Creating new policies
INFO Applying policies for ubuntu24-kde (machine: true)
DEBUG Refresh subscription state
DEBUG Applying dconf policy to ubuntu24-kde
DEBUG Ubuntu Pro is not enabled for GPO restrictions
DEBUG Filtering Rules
WARNING Rules from the following policy types will be filtered out as the machine is not enrolled to Ubuntu Pro: certificate
DEBUG Applying scripts policy to ubuntu24-kde
DEBUG Applying mount policy to ubuntu24-kde
DEBUG Cleaning up mount policy files for "ubuntu24-kde"
DEBUG No entries found for the apparmor machine policy
DEBUG Applying privilege policy to ubuntu24-kde
DEBUG ApplyPolicy gdm policy
DEBUG Applying dconf policy to gdm
DEBUG Update user profile /etc/dconf/profile/gdm
DEBUG Analyzing entry {Key:com/ubuntu/login-screen/background-picture-uri Value:/usr/share/backgrounds/Clouds_by_Tibor_Mokanszki.jpg Disabled:false Meta:s Strategy: Err:<nil>}
Applying user settings
DEBUG Connecting as [[33242:528960]]
DEBUG New request /service/UpdatePolicy
DEBUG Requesting with parameters: IsComputer: false, All: false, Target: <user>, Krb5Cc: /tmp/krb5cc_1580861359_8s9au0, Purge: false
DEBUG NormalizeTargetName for "<user>", type "user"
DEBUG Target name normalized to "<user>@user.domain"
DEBUG Check if grpc request peer is authorized
DEBUG Authorized as being administrator
DEBUG GetPolicies for "<user>@user.domain", type "user"
DEBUG Triggering autodiscovery of AD server triggered because sssd.conf does not provide an ad_server for "computer.domain"
DEBUG Getting gpo list with arguments: "--objectclass user *RODC*.computer.domain <user>@user.domain"
ERROR Error from server: error while updating policy: can't get policies for "<user>@user.domain": failed to retrieve the list of GPO (exited with 1): exit status 1
INFO: Current debug levels:
all: 10
tdb: 10
printdrivers: 10
lanman: 10
smb: 10
rpc_parse: 10
rpc_srv: 10
rpc_cli: 10
passdb: 10
sam: 10
auth: 10
winbind: 10
vfs: 10
idmap: 10
quota: 10
acls: 10
locking: 10
msdfs: 10
dmapi: 10
registry: 10
scavenger: 10
dns: 10
ldb: 10
tevent: 10
auth_audit: 10
auth_json_audit: 10
kerberos: 10
drs_repl: 10
smb2: 10
smb2_credits: 10
dsdb_audit: 10
dsdb_json_audit: 10
dsdb_password_audit: 10
dsdb_password_json_audit: 10
dsdb_transaction_audit: 10
dsdb_transaction_json_audit: 10
dsdb_group_audit: 10
dsdb_group_json_audit: 10
Processing section "[printers]"
Processing section "[print$]"
pm_process() returned Yes
Security token SIDs (1):
SID[ 0]: S-1-5-18
Privileges (0xFFFFFFFFFFFFFFFF):
Privilege[ 0]: SeMachineAccountPrivilege
Privilege[ 1]: SeTakeOwnershipPrivilege
Privilege[ 2]: SeBackupPrivilege
Privilege[ 3]: SeRestorePrivilege
Privilege[ 4]: SeRemoteShutdownPrivilege
Privilege[ 5]: SePrintOperatorPrivilege
Privilege[ 6]: SeAddUsersPrivilege
Privilege[ 7]: SeDiskOperatorPrivilege
Privilege[ 8]: SeSecurityPrivilege
Privilege[ 9]: SeSystemtimePrivilege
Privilege[ 10]: SeShutdownPrivilege
Privilege[ 11]: SeDebugPrivilege
Privilege[ 12]: SeSystemEnvironmentPrivilege
Privilege[ 13]: SeSystemProfilePrivilege
Privilege[ 14]: SeProfileSingleProcessPrivilege
Privilege[ 15]: SeIncreaseBasePriorityPrivilege
Privilege[ 16]: SeLoadDriverPrivilege
Privilege[ 17]: SeCreatePagefilePrivilege
Privilege[ 18]: SeIncreaseQuotaPrivilege
Privilege[ 19]: SeChangeNotifyPrivilege
Privilege[ 20]: SeUndockPrivilege
Privilege[ 21]: SeManageVolumePrivilege
Privilege[ 22]: SeImpersonatePrivilege
Privilege[ 23]: SeCreateGlobalPrivilege
Privilege[ 24]: SeEnableDelegationPrivilege
Rights (0x 0):
added interface enp0s31f6 ip=192.168.123.70 bcast=192.168.123.255 netmask=255.255.255.0
added interface enp0s31f6 ip=192.168.123.70 bcast=192.168.123.255 netmask=255.255.255.0
resolve_lmhosts: Attempting lmhosts lookup for name *RODC*.computer.domain<0x20>
startlmhosts: Can't open lmhosts file /etc/samba/lmhosts. Error was No such file or directory
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'ncalrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'http_negotiate' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Starting GENSEC mechanism spnego
Starting GENSEC submechanism gssapi_krb5
Ticket in credentials cache for <user>@user.domain will expire in 35988 secs
gensec_update_send: gssapi_krb5[0x12ee1680]: subreq: 0x12eaa3b0
gensec_update_send: spnego[0x12f282f0]: subreq: 0x12f22b70
gensec_update_done: gssapi_krb5[0x12ee1680]: NT_STATUS_MORE_PROCESSING_REQUIRED tevent_req[0x12eaa3b0/source4/auth/gensec/gensec_gssapi.c:1059]: state[2] error[0 (0x0)] state[struct gensec_gssapi_update_state (0x12eaa590)] timer[(nil)] finish[source4/auth/gensec/gensec_gssapi.c:1070]
gensec_update_done: spnego[0x12f282f0]: NT_STATUS_MORE_PROCESSING_REQUIRED tevent_req[0x12f22b70/auth/gensec/spnego.c:1631]: state[2] error[0 (0x0)] state[struct gensec_spnego_update_state (0x12f22d50)] timer[(nil)] finish[auth/gensec/spnego.c:2116]
gensec_gssapi: NO credentials were delegated
GSSAPI Connection will be cryptographically sealed
gensec_update_send: gssapi_krb5[0x12ee1680]: subreq: 0x12eaa3b0
gensec_update_send: spnego[0x12f282f0]: subreq: 0x12f22b70
gensec_update_done: gssapi_krb5[0x12ee1680]: NT_STATUS_OK tevent_req[0x12eaa3b0/source4/auth/gensec/gensec_gssapi.c:1059]: state[2] error[0 (0x0)] state[struct gensec_gssapi_update_state (0x12eaa590)] timer[(nil)] finish[source4/auth/gensec/gensec_gssapi.c:1077]
gensec_update_done: spnego[0x12f282f0]: NT_STATUS_OK tevent_req[0x12f22b70/auth/gensec/spnego.c:1631]: state[2] error[0 (0x0)] state[struct gensec_spnego_update_state (0x12f22d50)] timer[(nil)] finish[auth/gensec/spnego.c:2116]
Searching for account failed with: Failed to find account <user>
Fehler beim Festlegen der Benutzerberechtigung
Steps to reproduce it
- Setup two domains in a forest
- user in one, computer in another
- set all Domain Controler as GC
Ubuntu users: System information
No response
Non Ubuntu users: System information
Environment
- adsys version:
0.14.3(but same problem with 0.16.3) - Distribution:
Ubuntu - Distribution version:
24.04.2 - sssd:
2.9.4
Application settings
adsys.yml:
verbose: 2
Additional information
No response
Double check your logs
- [x] I have redacted any sensitive information from the logs
Hey, @ToastKiste21! Thanks for reporting the issue!
And wow... This is a complicated one. So... You have multiple domains in a single forest but with no relationship between them? Or is the user.domain a child of computer.domain?
Usually (I could be wrong though), the global catalog is assigned to the parent domain, and that's probably what SSSD is assuming as well (if the domains have this kind of relationship).
How does it work on your Windows machines? Do they require additional configuration, or are they able to figure that out right out of the box?
Either way, this looks more like a discovery issue within SSSD, and it's probably better if you raise your issue with them, as they might be able to help you better with it.
Not quite, we have a Forest and 2/3(test) domains under the main (user.domain). user.domain/ ├── computer.domain ├── test.domain
It's more like the computer.domain is a child of the user.domain.
I also created this issue in the SSSD GitHub repository (7957), but they told me it's more of an issue with Adsys because SSSD expects only computer GPOs, not user GPOs.
The thing is, our DCs only have their own GPOs - they know the other domains exist, but they don’t have their GPOs locally.
We also have over 1,000 (probably over 4,000, not sure) Windows clients, and they manage to figure it out automatically — but I'll double-check with my colleagues.
EDIT:
Ah and if i disable the ADSys authentication with pam-auth-update the user can login without a problem.
I also found this bug(?), if the user is in a group of the other domain samDB get's the RefErr: DSID-0310084B error:
source4/dsdb/common/util_groups.c:161: dsdb_search for <GUID=****> failed: LDAP error 10 LDAP_REFERRAL - <0000202B: RefErr: DSID-0310084B, data 0, 1 access points
ref 1: 'gc._msdcs.user.domain:3268'
> <ldap://gc._msdcs.user.domain:3268/>
From what i see is that this should be not a problem if the group is either a local or universal group (source)
But this is more likely a bug from samba.
Ah and if i disable the ADSys authentication with pam-auth-update the user can login without a problem.
That's expected. When adsys can't fetch the GPOs, we can't know for sure if the machine or the user complies with the demands of the AD controller, thus, it would be a security risk to allow the user to authenticate.
But this is more likely a bug from samba.
I wouldn't be surprised, tbh. We had some issues before with Samba not handling multiple domain environments recently.
Did you try configuring both domains on sssd.conf? Adsys uses that config file to figure out some domain information.
I wouldn't be surprised, tbh. We had some issues before with Samba not handling multiple domain environments recently.
Yeah, i've seen some mentioning about this.
Did you try configuring both domains on sssd.conf? Adsys uses that config file to figure out some domain information.
Yes i tried it. I also set the ad_server for the user.domain but it's used alwas the computer.domain. Looks like adsys is not recognizing that the user is in another domain and will use this DC.
Yes i tried it.
Can you send me the configuration that you changed? I'd like to see what you did, maybe it was not enough. In the meantime, I'll also go through the GPO download flow to see if I can spot any inconsistency.
Since it's a really specific issue, I need to try and help you through here instead of trying to reproduce everything myself (as it would likely not match your case).
This is the sssd.conf file configured for a multi-domain setup:
[sssd]
services = nss, pam, pac
domains = computer.domain, user.domain
default_domain_suffix = user.domain
config_file_version = 2
###############################################################################
# Child-Domäne
###############################################################################
[domain/computer.domain]
id_provider = ad
access_provider = ad
ad_domain = computer.domain
krb5_realm = COMPUTER.DOMAIN
#ad_server = *dc*.computer.domain,*dc*.computer.domain,*dc*.computer.domain
#ldap_uri = ldap://*dc*.computer.domain:3268
#ldap_schema = AD
#ldap_referrals = false
#ldap_id_mapping = true
#krb5_keytab = /etc/krb5.keytab/
#ad_gpo_access_control = enforcing
#ad_allow_remote_domain_local_groups = true
#ldap_use_tokengroups = true
###############################################################################
# Root-Domäne
###############################################################################
[domain/user.domain]
id_provider = ad
access_provider = ad
ad_domain = user.domain
krb5_realm = USER.DOMAIN
#ad_server = *dc*.user.domain, *dc*.user.domain, *dc*.user.domain
ldap_uri = ldap://*dc*.user.domain:3268
#ldap_referrals = false
#ldap_id_mapping = true
#ad_gpo_access_control = permissive
#ad_allow_remote_domain_local_groups = true
#ldap_use_tokengroups = true
I also attached the SSSD logs. I can confirm that the correct RODC is found.
What I'm unsure about is where adsys gets the FQDN to retrieve the GPOs. The error occurs in ad.go at line 259. However, I'm not sure whether the log output shows the actual FQDN.
When I manually set the FQDN for ObjectClass.user in adsys-gpolist, I use the following logic:
accountname = args.accountname
fqdn = args.fqdn
# → Für User-GPOs hart auf Root-DC umschalten
if args.objectclass == ObjectClass.user:
fqdn = '*dc*.user.domain'
accountname = args.accountname
# Users don’t need @, as we already have the specific-domain ticket
if args.objectclass == ObjectClass.user:
accountname = accountname.split('@')[0]
Even though the FQDN isn't explicitly shown in the debug output, the connection is made to the correct server (GPOs are retrieved). However, there's still the issue related to Samba.