Nt_status_access_denied

UCS - Univention Corporate Server
#1

Hallo,

wir testen unser Produkt opsi aktuell auf diversen UCS 5.0 Rollen. Aktuell funktioniert es auf einem Memberserver problemlos.
Auf allen anderen Rollen kriegen wir Probleme wenn wir von einem Client aus einem Miniroot den zuvor eingerichteten SMB Share mounten wollen mit der Meldung Permission Denied

Der Einfachheit halber habe ich nun einen UCS 5.0 Master genommen und veruscht mittels smbclient auf den Share zu verbinden

smbclient -U pcpatch //10.100.236.111/opsi_depot
lpcfg_do_global_parameter: WARNING: The "syslog" option is deprecated
Enter WORKGROUP\pcpatch's password: 
Try "help" to get a list of possible commands.
smb: \> ls
NT_STATUS_ACCESS_DENIED listing \*
smb: \> q

Der gewünschte Share liegt unter /var/lib/opsi/depot und hat folgende Berechtigungen

getfacl /var/lib/opsi/depot/
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: var/lib/opsi/depot/
# owner: opsiconfd
# group: opsifileadmins
# flags: -s-
user::rwx
group::rwx
other::---

Der user pcpatch wurde per udm Befehl angelegt ist auch in der Oberfläche verfügbar und ist Mitglied der Gruppe opsifileadmins

getent group opsifileadmins
opsifileadmins:*:5075:pcpatch,opsiconfd,adminuser

Was mir etwas komisch vorkommt ist die Tatsache dass das UID auf SID Mapping nicht korrekt zu sein scheint

# id pcpatch
uid=2009(pcpatch) gid=5075(opsifileadmins) Gruppen=5075(opsifileadmins)

# wbinfo -n pcpatch
S-1-5-21-747737302-4010260580-411728646-1115 SID_USER (1)

# wbinfo --uid-to-sid=2009
S-1-5-21-2911367237-2184100041-1077561524-1115

# wbinfo --sid-to-uid=S-1-5-21-2911367237-2184100041-1077561524-1115
2009

# wbinfo --sid-to-uid=S-1-5-21-747737302-4010260580-411728646-1115
3000016

# net getdomainsid
SID for domain MAS-OPSI-EXP is: S-1-5-21-747737302-4010260580-411728646

# wbinfo --domain MAS-OPSI-EXP -n pcpatch
S-1-5-21-747737302-4010260580-411728646-1115 SID_USER (1)
# wbinfo --domain MASTER236-50 -n pcpatch
S-1-5-21-747737302-4010260580-411728646-1115 SID_USER (1)

Es existieren 2 SIDs für den user pcpatch, was wahrscheinlich zu diesem Problem führt.

Hat jemand einen Tip wo ich noch schauen/suchen soll?

Gruß
Mathias

#2

Hallo Mathias,

In meiner Umgebung liefert ein ls bei smbclient den Inhalt der Verzeichnisse und Dateien.

Allerdings sind an der Freigabe erweiterete Samba-Einstellungen aktiviert - vielleicht fehlt das?

follow symlinks = yes
read list = pcpatch

Von der UIB wird ein Skript opsi-set-rights mitgeliefert, vielleicht hilft es dies auszuführen?

#3

Hallo Andreas,

diese Dinge sind es leider nicht.
Was wir uns aktuell fragen ist, wieso existieen zwei verschiedene SIDs für den user pcpatch?
S-1-5-21-2911367237-2184100041-1077561524-1115
und
S-1-5-21-747737302-4010260580-411728646-1115

root@master236-50:~# univention-ldapsearch uid=pcpatch | grep SID
sambaPrimaryGroupSID: S-1-5-21-2911367237-2184100041-1077561524-1113
sambaSID: S-1-5-21-2911367237-2184100041-1077561524-1115
root@master236-50:~# wbinfo -n pcpatch
S-1-5-21-747737302-4010260580-411728646-1115 SID_USER (1)

Scheint so als seien das openLDAP und Samba Domain nicht synchron und daher gibt es dann die Probleme.

Im connector-s4.log finde ich folgendes

ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server", 'errno': 111, 'info': 'Connection refused'}

Der Dienst läuft aber.
und hat auch mal was gemacht mit dem pcpatch user

connector-s4.log:26.01.2022 18:33:57.627 LDAP        (PROCESS): sync UCS > AD: [          user] [       add] 'cn=pcpatch,cn=users,DC=ucs,DC=master-opsi,DC=experimental42'
connector-s4.log:26.01.2022 18:33:58.785 LDAP        (PROCESS): sync AD > UCS: [          user] [    modify] 'uid=pcpatch,cn=users,dc=ucs,dc=master-opsi,dc=experimental42'
connector-s4.log:26.01.2022 18:34:04.844 LDAP        (PROCESS): sync UCS > AD: [          user] [    modify] 'cn=pcpatch,cn=users,DC=ucs,DC=master-opsi,DC=experimental42'
connector-s4.log:26.01.2022 18:34:04.869 LDAP        (PROCESS): sync UCS > AD: [          user] [    modify] 'cn=pcpatch,cn=users,DC=ucs,DC=master-opsi,DC=experimental42'
connector-s4.log:26.01.2022 18:41:51.079 LDAP        (PROCESS): sync UCS > AD: [          user] [    modify] 'cn=pcpatch,cn=users,DC=ucs,DC=master-opsi,DC=experimental42'
connector-s4.log:26.01.2022 18:41:52.145 LDAP        (PROCESS): sync AD > UCS: [          user] [    modify] 'uid=pcpatch,cn=users,dc=ucs,dc=master-opsi,dc=experimental42'
connector-s4.log:26.01.2022 18:41:58.189 LDAP        (PROCESS): sync UCS > AD: [          user] [    modify] 'cn=pcpatch,cn=users,DC=ucs,DC=master-opsi,DC=experimental42'
connector-s4.log:26.01.2022 18:45:09.411 LDAP        (PROCESS): sync UCS > AD: [          user] [    modify] 'cn=pcpatch,cn=users,DC=ucs,DC=master-opsi,DC=experimental42'
connector-s4.log:26.01.2022 18:45:10.443 LDAP        (PROCESS): sync AD > UCS: [          user] [    modify] 'uid=pcpatch,cn=users,dc=ucs,dc=master-opsi,dc=experimental42'
connector-s4.log:26.01.2022 19:02:53.432 LDAP        (PROCESS): sync AD > UCS: [          user] [    modify] 'uid=pcpatch,cn=users,dc=ucs,dc=master-opsi,dc=experimental42'
connector-s4.log:27.01.2022 08:13:09.176 LDAP        (PROCESS): sync AD > UCS: [          user] [    modify] 'uid=pcpatch,cn=users,dc=ucs,dc=master-opsi,dc=experimental42'
connector-s4.log:27.01.2022 08:13:15.240 LDAP        (PROCESS): sync UCS > AD: [          user] [    modify] 'cn=pcpatch,cn=users,DC=ucs,DC=master-opsi,DC=experimental42'

ldapsearch liefert auch ein Ergebnis, ist also da und antwortet.

#4

ja, das ist so nicht gut - in meiner Umgebung sind die SIDs gleich im LDAP und Samba.

Spannend wäre, was in Samba direkt drin steht
univention-s4search cn=pcpatch | grep Sid

Und ob die Datenbank in einem guten Zustand ist
samba-tool dbcheck --cross-ncs --fix --yes

Die unterschiedlichen SIDs lassen sich sicherlich Samba-Seitig gerade ziehen. Vielleicht ist es aber einfacher den Benutzer “pcpatch” zu entfernen und neu anzulegen.

#5

Hier die Outputs der Befehle

root@master236-50:/var/log/univention# univention-s4search cn=pcpatch | grep Sid
Processing section "[netlogon]"
Processing section "[sysvol]"
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Processing section "[opsi_images]"
Processing section "[opsi_depot_rw]"
Processing section "[opsi_workbench]"
Processing section "[opsi_depot]"
pm_process() returned Yes
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 'naclrpc_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
added interface lo ip=::1 bcast= netmask=ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
added interface lo ip=127.0.0.1 bcast=127.255.255.255 netmask=255.0.0.0
added interface ens18 ip=10.100.236.111 bcast=10.100.255.255 netmask=255.255.0.0
added interface lo ip=::1 bcast= netmask=ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
added interface lo ip=127.0.0.1 bcast=127.255.255.255 netmask=255.0.0.0
added interface ens18 ip=10.100.236.111 bcast=10.100.255.255 netmask=255.255.0.0
Received smb_krb5 packet of length 394
Received smb_krb5 packet of length 222
objectSid: S-1-5-21-747737302-4010260580-411728646-1115

und

root@master236-50:/var/log/univention# samba-tool dbcheck --cross-ncs --fix --yes
Processing section "[netlogon]"
Processing section "[sysvol]"
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Processing section "[opsi_images]"
Processing section "[opsi_depot_rw]"
Processing section "[opsi_workbench]"
Processing section "[opsi_depot]"
pm_process() returned Yes
Checking 3661 objects
Checked 3661 objects (0 errors)

Das Problem betrifft nicht nur den pcpatch user, sondern auch den administrativen user den wir mittels umd Befehl angelegt haben.

Der adminuser wird mit folgendem Befehl angelegt

udm users/user create --position=cn=users,dc=ucs,dc=master-opsi,dc=experimental42 --set username=adminuser --set 'description=opsi admin user' --set primaryGroup=cn=opsiadmin,cn=groups,dc=ucs,dc=master-opsi,dc=experimental42 --set lastname=adminuser --set password=linux123 --set overridePWLength=1 --ignore_exists

Der pcpatch user wird im opsi join skript mit folgendem Befehl angelegt

udm users/user create "$@" \
        --position="cn=users,$ROOT_DN" \
        --set username="pcpatch" \
        --set description="opsi-pseudo user" \
        --set unixhome="/var/lib/opsi" \
        --set primaryGroup="cn=$fileadmingroup,cn=groups,$ROOT_DN" \
        --set lastname="pcpatch" \
        --set password="${pcpatchpassword}" \
        --set overridePWLength=1 \
        --ignore_exists
#6

Ok ich glaube wir haben das Problem gelöst.

Wir installieren ucs 5.0-1 per Netboot und preseeding
In der Preseed steht ein einfaches Passwort, linux123. Der Installer hat es nicht angemeckert und daher schien es ok zu sein. Jedoch war im installierten System der Login mit dem Administrator Nutzer nicht möglich und univention-portal war nicht sauber gejoined.
Habe daraufhin das profile unter /var/cache/univention-system-setup editiert. Hierfür die root_password Zeile gelöscht und neu angelegt mit gleichem einfachen Passwort.
system-join.sh ausgeführt, univention-portal war sauber gejoined und der Administrator Nutzer konnte für den Login in der Oberfläche genutzt werden.
Der Aufruf von setup-join.sh hat eine neue SID erzeugt und so sind LDAP und Samba SIDs auseinander gelaufen.

Zumindest hat eben der Login per smbclient geklappt und ein ls lieferte auch ein Listing

smbclient -U pcpatch //10.100.236.111/opsi_depot
lpcfg_do_global_parameter: WARNING: The "syslog" option is deprecated
Enter WORKGROUP\pcpatch's password: 
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Mon Jan 31 11:21:02 2022
  ..                                  D        0  Mon Jan 31 11:18:15 2022
  opsi_nfs_share                      D        0  Tue Sep  8 09:49:24 2020
  opsi-script                         D        0  Mon Jan 31 11:21:03 2022

		31401744 blocks of size 1024. 24087308 blocks available
smb: \> exit
Mastodon