Solaris 11.4: Probleme als AD-Mitglied

martingo · 10.09.2018

Hallo,

ich versuche, mein Solaris 11.4 mit napp-it als Mitglied in das AD zu bringen. Habe gestern den ganzen Tag damit verbracht, bekomme aber immer wieder Fehler.
Zunächst: Das Beitreten der Domäne funktioniert in 99% der Fälle auf Anhieb. Dazu habe ich idmap von winuser:Administrator auf unixuser:root

Wenn ich dann aber auf einen Share zugreifen will, dann dauert das meist einige Zeit und irgendwann funktioniert es dann auch. Berechtigungen über Windows Sicherheit kann ich aber nicht setzen, weil immer im Rechnerpfad gesucht wird, nicht aber in der Domäne.
Grundsätzlich funktioniert die Verbindung von Solaris zum DC aber nicht richtig. Ich bekomme ständig folgende Nachricht in der Solaris Konsole:

Diese Nachrichten finde ich auch nur auf der Konsole, nicht aber unter /var/log/

Die Windows Sicherheit sieht wie folgt aus:

Als Domain Controller war eigentlich UCS geplant: UCS - Univention Corporate Server für unkomplizierte IT Univention
Testweise habe ich dann auch den Turnkey Domain Controller versucht: Domain Controller - free Active Directory server | TurnKey GNU/Linux
Bei beiden das gleiche Problem. Insofern würde ich mal grundsätzlich mein Solaris als Ursache annehmen.

Die DCs laufen (immer nur einer zu gleichen Zeit) als VM auf Proxmox. Solaris läuft Bare-Metal. Die Server stehen nebeneinander und sind per Switch direkt verbunden. Lassen sich logischweise auch gegenseitig pingen (<1ms) usw.
Solaris war ursprünglich von beta auf Final aktualisiert, testweise habe ich es aber auch komplett neu installiert -> keinerlei Änderung. Einen Windows Server als DC habe ich nicht testweise zur Verfügung.

Ich bin mit meinem Latein ziemlich am Ende, habe fast den ganzen gestrigen Tag damit verblödelt und bin kurz davor, die Rechtevergabe ohne AD zu machen. Hat noch jemand eine Idee, woran es liegen könnte?

Viele Grüße
Martin

Edit: Testweise mal LM Authentication Level 2 geutzt, statt wie bisher Level 4: da gleiche in gün.

katzenhai · 10.09.2018

Probier mal einen anderen User zum Beitritt zur Domäne zu benutzen.

martingo · 10.09.2018

Hmm, das ist halt der standardmäßige Domainadmin. Soll ich einfach einen weiteren User anlegen, ihn in die Domainadmin Gruppe packen und neu joinen? Zielt Deine Anregung auf einen bestimmten Hintergrund ab?

Morpheuz · 10.09.2018

Wenn nicht anders eingestellt, dürfen alle DomainUser 10 Rechner in die AD bringen.

martingo · 10.09.2018

Also ein testweise erstellter User "TestUser" ohne besondere Gruppe (unter Turnkey keine Gruppe, unter UCS nur DomainUsers) darf nicht joinen, es kommt ACCESS_DENIED.
Ein unter UCS testweise erstellter User "TestAdmin" mit Gruppe DomainAdmins darf joinen, es ändert sich am Fehlerbild allerdings nichts. Beim Verbinden des Shares ist noch auffällig: Erster Versuch dauert ewig, dann kommt Kennwort falsch, zeitgleich in der Solaris Konsole die HOST_UREACHABLE Meldung. Der zweite Versuch klappt dann normalerweise sofort. Windows Sicherheit ist aber trotzdem nicht möglich und im Hintergrund kommt die Meldung immer wieder mal.

Was ich vorhin bei den Screenshots vergessen hatte, ist noch diese Meldung. Kommt sofort nach dem Joinen und auch sonst immer wieder mal:

Edit: Groß-/Kleinschreibung des Rechnernamens dürfte ja keine Rolle spielen, oder? Der Rechnername ist klein geschrieben seu-nappit-a. Sowohl unter UCS als auch Turnkey ist der Rechnername dann aber groß geschrieben. Unter UCS ist der DC klein geschrieben aufgeführt (seu-ucs-a), SEU-NAPPIT-A aber groß.

gea · 10.09.2018

Ich habe meinen Solaris 11.4 probehalber per napp-it in unsere Domäne aufgenommen (Windows 2016) und mich selbst auf root gemappt. Ich konnte mich dann problemlos mit meinem AD Account verbinden und Rechte für AD Benutzer und Gruppen vergeben. Das zugrundeliegende Dateisystem wurde mit defaults erstellt.

Der Domäne beitreten darf nur ein AD Admin. Das idmapping in Solaris dient nur dazu als beliebiger user Adminrechte zu erhalten. Ansonst müsste man sich als root per SMB verbinden.

Alternativ daher mal als root verbinden und schauen ob die AD user erscheinen. In Windows Sicherheit > Suchpfad > Gesamtes Verzeichnis, dann Sicherheit > Erweitert > Jetzt suchen (um alle anzuzeigen).

martingo · 10.09.2018

Hmm, auf der einen Seite gut zu wissen, dass es bei Dir geht. Auf der anderen Seite schlecht, weil mir echt die Ansätze ausgehen mittlerweile.
Hast Du irgendeine Idee, was ich noch probieren könnte?

gea · 10.09.2018

Es gibt ja jetzt drei Möglichkeiten. Entweder es geht nur mit einem Windows Server, Solaris ist irgendwo falsch konfiguriert oder man muss etwas beim UCS einstellen. Gut wäre jetzt ein Windows Server zum Vergleich.

VirtuGuy · 10.09.2018

Proxmox FW ist aktiv?
Ist die UCS Box als DNS in der VM eingetragen?
Wird ein Computer Objekt angelegt?
Etwaige Meldungen unter /var/log/univention/ ?

Seelbreaker · 10.09.2018

Morpheuz schrieb:
Wenn nicht anders eingestellt, dürfen alle DomainUser 10 Rechner in die AD bringen.

Da reden wir aber von einem Windows Domaincontroller.

Wie es die anderen Free-AD Varianten halten ist fraglich....

@TE: Wieso lädtst du dir nicht einfach ein Windows Server 2016 herunter, installierst da DC, DNS und testst die AD-Anbindung damit? Des Windows läuft auch für einige Zeit im Testmodus, also brauchst du dafür keine Lizenz.

Wenns mit Windows einwandfrei klappt, dann weißt du zumindest, dass deine Solaris Konfig für MS-ADs passen.

Wie schauts mit DNS aus? Auflösung des Domänen-Namen zeigt auf deinen AD-Server?

martingo · 10.09.2018

Nein, alles offen, Firewall Service von UCS auch zeitweilig deaktiviert
UCS VM ist als DNS auf dem Solaris Server eingetragen
Ja
Im connector-s4.log steht beim join, dass das Kerberos Objekt des Solaris Servers nicht gefunden wird.

Ich werde Mal die Solaris Doku zum ad Join durchgehen und das händisch versuchen.
Irgendwas passt da auch nicht. /usr/lib/krb5/klookup liefert bei mir immer Error state 1 ($?) ohne Ausgabe auf der Konsole. Daher schlägt auch kclient erstmal fehl, wenn ich die erste Frage nach non-solaris-dc mit N beantworte (wie in der UCS Doku beschrieben). Gleiches Problem wenn ich Heimdal wähle.

Mal eine grundlegende Frage: von diversen Linux Distributionen kenne ich es so, dass bei der Installation der FQDN abgefragt wird. Bei der Solaris Installation wird der Hostname abgefragt und später (optional) lediglich noch SuchdomainS Zuletzt hatte ich bei der Frage nach dem Hostname immer den FQDN angegeben. Testweise habe ich nochmal mit hostname (ohne ad.example.org) installiert. Der Fehler blieb bestehen und zusätzlich ständig in der Konsole die Meldung, dass Sendmail den FQDN nicht bestimmen konnte. In der Solaris Doku ist auch immer nur vom "Computernamen, über den man den Server im Netzwerk finden kann" die Rede.
Was ist korrekt bei der Installation? Hostname oder FQDN?

- - - Updated - - -

Sorry, die Antworten waren für VirtuGuys Fragen gedacht, da war ich etwas zu langsam. Man sollte doch das Zitieren nutzen

Ja, Windows Server mal testweise als VM zu installieren, hatte ich mir auch schon überlegt. 2016 Lizenz wäre vom vorherigen Server sogar noch vorhanden. Allerdings weiß ich nicht so recht, ob es mir viel bringt zu wissen, dass es mit Windows als DC läuft und der Aufwand bis der DC aufgesetzt ist, ist halt doch ganz ordentlich.

@gea: wie sehen deine Ausgaben von hostname und cat /etc/defaultdomain aus?

niklasschaefer · 10.09.2018

In dem Solaris Server muss zwingend der DNS vom Domain Controller stehen sonst funktionieren die Ad Dienste sehr langsam/träge oder garnicht. Daher mal bitte den DNS eintragen und schon sollte es laufen.

Gruß Niklas

VirtuGuy · 10.09.2018

Bitte mal prüfen ob ein Auflösen der SRV Einträge möglich ist => Testing the DNS Name Resolution - SambaWiki

Bezüglich der Kerberos Objekt Meldung, kannst du ggf den REst des Log´s bereitstellen?

besterino · 10.09.2018

Offtopic: ich les hier ja planlos nur mit und finde es trotzdem sensationell, wie Ihr hier mit dem Threadersteller nach der Lösung sucht! Dickes Kompliment an die mit Ahnung hier! /offtopic

gea · 11.09.2018

martingo schrieb:
@gea: wie sehen deine Ausgaben von hostname und cat /etc/defaultdomain aus?

hostname: solaris114
/etc/defaultdomain gibts bei mir nicht

univentionsupport · 11.09.2018

@marrtingo:
Moin, wir wollen mal versuchen, das Ding sauber in die Domäne zu bekommen. Es gibt ja glücklicherweise auf beiden Seiten schöne Logfiles.

Du hast geschrieben, dass Du die UCS-Doku schon kennst- welche meinst Du konkret? Es gibt ja eine Cool Solution, hast Du es danach versucht?

Weiterhin meintest Du, dass der Join selbst ja klappen würde, der Zugriff auf ein Share aber anfangs langsam bzw. garnicht kommt und erst beim Zweiten Versuch. Das ist ein Samba-Share, richtig? Es gibt bei uns auch einen Artikel, der die Fehlersuche bei Samba beschreibt, wenn Win nicht joinen kann- für die Fehlersuche auf Serverseite (egal ob Win oder Solaris) ist der auch hilfreich.

Ich würde vorschlagen, Schritt für Schritt vorzugehen. Nach dem Join sollten ja die AD/UCS-Nutzer dem Solaris bekannt sein. Zum Test könntest Du auf dem UCS einen NFS-Share anlegen, lokal als einer der Benutzer ein paar Dateien anlegen und den Share via NFS auf Solaris mounten. Zeigt das "ls -al" dann die Benutzernamen an oder nur IDs?

martingo · 11.09.2018

Wow, so viel Feedback hatte ich nicht erwartet, vielen Dank :love:

Also, mal der Reihe nach.

VirtuGuy schrieb:
Bitte mal prüfen ob ein Auflösen der SRV Einträge möglich ist => Testing the DNS Name Resolution - SambaWiki

DNS sieht meiner Meinung nach gut aus. Der Vollständigkeit halber mal alle Tests aus Deinem Link von der Samba Seite:

Code:

Last login: Tue Sep 11 11:42:19 2018 from 192.168.10.109
Oracle Corporation      SunOS 5.11      11.4    Aug 2018
You have new mail.
root@seu-nappit-a:~#
root@seu-nappit-a:~# nslookup seu-ucs-a.ad.example.de
Server:         192.168.10.10
Address:        192.168.10.10#53

Name:   seu-ucs-a.ad.example.de
Address: 192.168.10.10

root@seu-nappit-a:~#
root@seu-nappit-a:~# nslookup 192.168.10.10
Server:         192.168.10.10
Address:        192.168.10.10#53

10.10.168.192.in-addr.arpa      name = seu-ucs-a.ad.example.de.

root@seu-nappit-a:~#
root@seu-nappit-a:~# nslookup
> set type=SRV
> _ldap._tcp.ad.example.de
Server:         192.168.10.10
Address:        192.168.10.10#53

_ldap._tcp.ad.example.de       service = 0 100 389 seu-ucs-a.ad.example.de.
> exit

root@seu-nappit-a:~#
root@seu-nappit-a:~#

niklasschaefer schrieb:
In dem Solaris Server muss zwingend der DNS vom Domain Controller stehen sonst funktionieren die Ad Dienste sehr langsam/träge oder garnicht. Daher mal bitte den DNS eintragen und schon sollte es laufen.

Der DNS vom DC ist in Solaris eingetragen, siehe Post #11 und die Antwort auf VirtuGuys Frage zuvor.

VirtuGuy schrieb:
Bezüglich der Kerberos Objekt Meldung, kannst du ggf den REst des Log´s bereitstellen?

Das Logfile während des Joins sieht folgendermaßen aus. Davor und danach passiert in dem Log nichts weiter:

Code:

Univention DC Master 4.3-2:

The UCS management system is available at https://seu-ucs-a.ad.example.de/ (192.168.10.10)

You can log into the Univention Management Console - the principal tool to manage
users, groups, etc. - using the "Administrator" account and the password selected
for the root user on the master domain controller.

Last login: Mon Sep 10 16:04:09 2018 from 192.168.10.109
root@seu-ucs-a:~#

root@seu-ucs-a:~# tail -fn0 /var/log/univention/connector-s4.log

11.09.2018 11:52:30,932 LDAP        (PROCESS): sync to ucs:   [windowscomputer] [       add] cn=SEU-NAPPIT-A,CN=Computers,dc=ad,dc=example,dc=de
11.09.2018 11:52:31,246 LDAP        (ERROR  ): get_ucs_object: could not identify UDM object type: cn=SEU-NAPPIT-A,CN=Computers,dc=ad,dc=example,dc=de
11.09.2018 11:52:31,246 LDAP        (PROCESS): get_ucs_object: using default: users/user
11.09.2018 11:52:37,316 LDAP        (PROCESS): sync from ucs: [windowscomputer] [       add] cn=seu-nappit-a,cn=computers,DC=ad,DC=example,DC=de
11.09.2018 11:52:37,341 LDAP        (PROCESS): sync from ucs: [windowscomputer] [    modify] cn=seu-nappit-a,cn=computers,DC=ad,DC=example,DC=de
11.09.2018 11:52:37,345 LDAP        (PROCESS): sync from ucs: [windowscomputer] [    modify] cn=seu-nappit-a,cn=computers,DC=ad,DC=example,DC=de
11.09.2018 11:52:37,349 LDAP        (PROCESS): sync from ucs: [windowscomputer] [    modify] cn=seu-nappit-a,cn=computers,DC=ad,DC=example,DC=de
11.09.2018 11:52:38,364 LDAP        (PROCESS): sync to ucs:   [windowscomputer] [    modify] cn=seu-nappit-a,cn=computers,dc=ad,dc=example,dc=de

So sieht der Join über die nappit WebGUI aus:

univentionsupport schrieb:
Du hast geschrieben, dass Du die UCS-Doku schon kennst- welche meinst Du konkret? Es gibt ja eine Cool Solution, hast Du es danach versucht?

Korrekt, nach Deiner URL und der dort verlinkten Doku, wobei der dortige Abschnitt 2.4 (LDAP Anbindung) noch nicht fertig ist/funktioniert.
Probleme macht der kclient:

Code:

root@seu-nappit-a:~# kclient

Starting client setup

---------------------------------------------------
Is this a client of a non-Solaris KDC ? [y/n]: n
        No action performed.

seu-nappit-a does not have a DNS record and is required for Kerberos setup
---------------------------------------------------
Setup FAILED.

root@seu-nappit-a:~# kclient

Starting client setup

---------------------------------------------------
Is this a client of a non-Solaris KDC ? [y/n]: y
Which type of KDC is the server:
        ms_ad: Microsoft Active Directory
        mit: MIT KDC server
        heimdal: Heimdal KDC server
        shishi: Shishi KDC server
Enter required KDC type: heimdal

seu-nappit-a does not have a DNS record and is required for Kerberos setup
---------------------------------------------------
Setup FAILED.

root@seu-nappit-a:~#

Ursächlich dafür sind diese Zeilen in /usr/sbin/kclient:

Code:

2182 if [[ "$dns_state" == @(online|degraded) ]]; then
2183         client_machine=`$KLOOKUP`
2184
2185         if [[ $? -ne 0 ]]; then
2186                 if [[ $adddns == no ]]; then
2187                         printf "\n$(gettext "%s does not have a DNS record and is required for Kerberos setup")\n" $hostname >&2
2188                         error_message
2189                 fi

Das Binary klookup kann ich leider nicht weiter untersuchen, wieso es fehlschlägt. Aber es schlägt auch von der Konsole fehl:

Code:

root@seu-nappit-a:~# /usr/lib/krb5/klookup
root@seu-nappit-a:~# echo $?
1
root@seu-nappit-a:~#

univentionsupport schrieb:
Weiterhin meintest Du, dass der Join selbst ja klappen würde, der Zugriff auf ein Share aber anfangs langsam bzw. garnicht kommt und erst beim Zweiten Versuch. Das ist ein Samba-Share, richtig? Es gibt bei uns auch einen Artikel, der die Fehlersuche bei Samba beschreibt, wenn Win nicht joinen kann- für die Fehlersuche auf Serverseite (egal ob Win oder Solaris) ist der auch hilfreich.

Korrekt, der Join funktioniert. Es ist dann in der UCS WebGUI auch ein Rechner Objekt angelegt:

Ich versuche nun an einem Windows PC (der nicht in der Domäne ist) ein SMB/CIFS Share auf dem Solaris Server (der in der Domäne ist) zu verbinden. Meist ist es dann so, dass ich meinen Domänenadmin als User eingebe (der auf Solaris auf root gemappt ist) und nach etwa 30-60 Sekunden einen Fehler "ungültiges Kennwort" oder so erhalte. Zeitgleich erscheinen die Fehlermeldungen aus meinem ersten Post auf der Solaris Konsole. Der zweite Versuch klappt dann in der Regel ohne Zeitverzögerung, ich kann aber nicht auf Windows Sicherheit usw. zugreifen (die drei weiteren Screenshots aus dem ersten Post).

Viele Grüße
Martin

univentionsupport · 11.09.2018

martingo schrieb:
Also, mal der Reihe nach.

Besser, ja. Hier kommt nämlich einiges durcheinander.

DNS sieht meiner Meinung nach gut aus. Der Vollständigkeit halber mal alle Tests aus Deinem Link von der Samba Seite:

Du testest hier die DNS Auflösung des Masters (seu-ucs-a), das ich wichtig und auch richtig. Aaaaaber der kclient meckert doch an, dass er seinen eigenen Eintrag nicht finden kann:

Code:

root@seu-nappit-a:~# kclient

Starting client setup

---------------------------------------------------
Is this a client of a non-Solaris KDC ? [y/n]: n
        No action performed.

seu-nappit-a does not have a DNS record and is required for Kerberos setup
---------------------------------------------------
Setup FAILED.

Hier sucht er nach seu-nappit-a. Gibt es diesen Eintrag denn im DNS? nslookup hilft hier wieder. Hast Du auch beachtet:

Note: It's important to assign the computer object the MAC address of your Soalris client and an available IP address.

?
Ist der Solaris Rechner sauber im UCS-DNS eingetrgen? nslookup, wie oben.

Code:

11.09.2018 11:52:30,932 LDAP        (PROCESS): sync to ucs:   [windowscomputer] [       add] cn=SEU-NAPPIT-A,CN=Computers,dc=ad,dc=example,dc=de
11.09.2018 11:52:31,246 LDAP        (ERROR  ): get_ucs_object: could not identify UDM object type: cn=SEU-NAPPIT-A,CN=Computers,dc=ad,dc=example,dc=de
11.09.2018 11:52:31,246 LDAP        (PROCESS): get_ucs_object: using default: users/user
11.09.2018 11:52:37,316 LDAP        (PROCESS): sync from ucs: [windowscomputer] [       add] cn=seu-nappit-a,cn=computers,DC=ad,DC=example,DC=de
11.09.2018 11:52:37,341 LDAP        (PROCESS): sync from ucs: [windowscomputer] [    modify] cn=seu-nappit-a,cn=computers,DC=ad,DC=example,DC=de
11.09.2018 11:52:37,345 LDAP        (PROCESS): sync from ucs: [windowscomputer] [    modify] cn=seu-nappit-a,cn=computers,DC=ad,DC=example,DC=de
11.09.2018 11:52:37,349 LDAP        (PROCESS): sync from ucs: [windowscomputer] [    modify] cn=seu-nappit-a,cn=computers,DC=ad,DC=example,DC=de
11.09.2018 11:52:38,364 LDAP        (PROCESS): sync to ucs:   [windowscomputer] [    modify] cn=seu-nappit-a,cn=computers,dc=ad,dc=example,dc=de

Während des Joins erstellt Samba ein Computerobjekt. Mangels Informationen von Samba erstellt der UCS LDAP das dann als "users/user" bzw "Windows Workstation/ Server". Danach wird das Objekt wieder zu Samba gesynct. Bitte lösche das Objekt noch einmal, erstelle es als Linux-Computer (und nicht Windows Workstation) inkl. Mac-Adresse neu. Das ist aber eher ein Teil "sicher ist sicher"...

Ich versuche nun an einem Windows PC (der nicht in der Domäne ist) ein SMB/CIFS Share auf dem Solaris Server (der in der Domäne ist) zu verbinden.

Das wird so nicht funktionieren. Samba bzw. MS haben neue Sicherheitsdefinitionen eingeführt, so dass nicht verifizierbare Accounts nicht mehr auf Nutzer "gemapt" werden! Joine das Windows-System ebenfalls in die Domäne, anders wird das nicht funktionieren.
Ich gehe davon aus, dass Du die neueste UCS-Version einsetzt, ja?

Meist ist es dann so, dass ich meinen Domänenadmin als User eingebe (der auf Solaris auf root gemappt ist) und nach etwa 30-60 Sekunden einen Fehler "ungültiges Kennwort" oder so erhalte.

Auch das wird nicht funktionieren. Zumindest nicht sorgenfrei, wie Du gemerkt hast. Du versuchst Dich mit einem Domänenbenutzer anzumelden, der von Solaris auf einen lokalen Nutzer gemappt wird. Da kann die Domänenberechtigung ja nicht klappen!

- - - Updated - - -

Ach, noch eine Ergänzung.

Allerdings bin ich mir da nicht so sicher, wie Solaris das handhabt.

Lt. der Doku soll der DHCP-Server verwendet werden. Vermutlich, um die richtige Verwendung der Domain-Search Liste sicherzustellen. Ist beim UCS nämlich der DHCP-Server aktiviert, übergibt er die Liste der Search Domains an den DHCP-Client (in dem Falle ja Solaris als auch Windows-Clients). Fehlt diese oder ist sie unterschiedlich, klappt das mit der DNS-Auflösung natürlich nicht.

Und noch etwas: Die Zeit sollte UNBEDINGT bei allen Beteiligten identisch sein! Gerade in virtualisierten Umgebungen laufen die Zeiten gerne mal auseinander. Am besten auch auf dem Solaris-System den ntpd aktivieren und von UCS syncen lassen.

Und beim UCS einen externen NTP-Server eintragen.

/CV

martingo · 11.09.2018

So ganz leuchtet mir das nicht ein. Wenn ich unter WSE2016 einen Rechner in die Domäne aufnehme, braucht dieser Rechner weder eine fixe IP, noch muss der DC der DHCP Server sein, noch muss ich vorab die IP in den DNS des Servers eintragen.
Für meine Server könnte ich damit noch leben, die sollen eh in die Domäne.

Aber jeden Client PC, der auf Netzwerk Shares zugreifen soll? Das kommt nicht in Frage. Da verzichte ich lieber ganz aufs AD. Und sowohl unter WSE als auch WSS 2016 kann ich mit non-Domain-Clients über die AD-Zugangsdaten auf Shares zugreifen. Ich hatte fast zwei Jahre ein paar Notebooks in einem WS 2016 AD und mehrere PCs außerhalb der Domäne.
Der DC war nicht der DHCP-Server und ich konnte mich mit allen Windows PCs auf die Shares verbinden.

gea · 11.09.2018

Damit AD Nutzer mit einem Domänenaccount auf einen AD-Memberserver zugreifen können, müssen deren PCs nicht selbst Mitglied der Domäne sein. Man muss lediglich beim SMB Zugriff den Domänenaccount z.B. name@domain.xx benutzen. Ist der PC AD-Member wird automatisch der AD Account der lokalen Anmeldung auf allen AD Servern genutzt. Es entfällt die Einzel-Anmeldung was bei mehreren Servern extrem angenehm ist.

PC Clients können durchaus einen anderen DNS z.B. Googles 8.8.8.8 benutzen. Den Server DNS Eintrag würde ich aber immer auf den AD setzen. Zeitsyncronisierung ist kritisch vor allem beim Beitritt zur Domäne aber auch nachher. DHCP ist nicht nötig. Man kann auch mit statischen ip arbeiten oder einen anderen DHCP Server nutzen.

VirtuGuy · 11.09.2018

martingo schrieb:
So ganz leuchtet mir das nicht ein. Wenn ich unter WSE2016 einen Rechner in die Domäne aufnehme, braucht dieser Rechner weder eine fixe IP, noch muss der DC der DHCP Server sein, noch muss ich vorab die IP in den DNS des Servers eintragen.
Für meine Server könnte ich damit noch leben, die sollen eh in die Domäne..

Ein Windows DC legt dir einen "Dummy" DNS Eintrag an wenn es keinen DHCP gibt der sich darum kümmert. Der Eintrag liegt dann halt ggf in einer gänzlich falschen Zone, in größeren Netzen wird dies schnell etwas unübersichtlich.

martingo schrieb:
Aber jeden Client PC, der auf Netzwerk Shares zugreifen soll? Das kommt nicht in Frage. Da verzichte ich lieber ganz aufs AD. Und sowohl unter WSE als auch WSS 2016 kann ich mit non-Domain-Clients über die AD-Zugangsdaten auf Shares zugreifen. Ich hatte fast zwei Jahre ein paar Notebooks in einem WS 2016 AD und mehrere PCs außerhalb der Domäne.
Der DC war nicht der DHCP-Server und ich konnte mich mit allen Windows PCs auf die Shares verbinden.

Die Frage ist halt welchen Bedarf man hat. Normalerweise möchte man gerade die Clients in einer Domain haben, bei den Servern kann man zur Not etwas basteln. Ich würde zuerst mal beim fehlenden DNS Namen ansetzen, ev lösen sich dann deine Probleme von alleine.

Du hast im Grunde durchaus noch andere Möglichkeiten wenn du die Clients nicht in der Domain haben willst:

1. Security zurück schrauben und mit dem alten NTLM Kram arbeiten
2. du kannst mal mit "ksetup" auch ohne Domain Join dein Ticket holen - hab ich selbst nur bei Kursen gelernt aber nie probiert

Bei neueren Windows 10 und 2019er Builds ist der ganze smb1 Kram per deaktiviert, von daher hast du auch hier früher oder später das selbe Problem. Aktuell gibt es kein Datum wenn smb1 gänzlich raus fliegt, von daher bleibt es wohl noch länger die einfachste Option.

univentionsupport · 12.09.2018

martingo schrieb:
So ganz leuchtet mir das nicht ein. Wenn ich unter WSE2016 einen Rechner in die Domäne aufnehme, braucht dieser Rechner weder eine fixe IP, noch muss der DC der DHCP Server sein, noch muss ich vorab die IP in den DNS des Servers eintragen.
Für meine Server könnte ich damit noch leben, die sollen eh in die Domäne.

Es wurde nirgendwo gesagt, dass der DC auch DHCP sein musss. Es geht aber darum, mögliche Schwierigkeiten auszuschalten. Demnach bietet es sich an, alles nach Dokumentation zu machen. Es steht Dir frei, dass auch anders zu machen. Aber dann wird die Fehlersuche halt schwieriger. Insbesondere für uns von außerhalb. :coffee:

Aber jeden Client PC, der auf Netzwerk Shares zugreifen soll [in die Domäne]? Das kommt nicht in Frage.

Öhmmmm.... doofe Frage: Warum willst Du dann überhaupt eine Domäne aufbauen? :confused:

/CV

martingo · 12.09.2018

univentionsupport schrieb:
Es wurde nirgendwo gesagt, dass der DC auch DHCP sein musss.

->

univentionsupport schrieb:
Lt. der Doku soll der DHCP-Server verwendet werden.
...
Und noch etwas: Die Zeit sollte UNBEDINGT bei allen Beteiligten identisch sein! Gerade in virtualisierten Umgebungen laufen die Zeiten gerne mal auseinander. Am besten auch auf dem Solaris-System den ntpd aktivieren und von UCS syncen lassen.

Zeit wurde zuvor zwischen den beiden synchronisiert.

univentionsupport schrieb:
Warum willst Du dann überhaupt eine Domäne aufbauen?

Ich sage nicht, dass keine Clients in die Domäne sollen/dürfen. Aber der Zugriff muss auch für Clients außerhalb der Domäne möglich sein. Solange das nicht der Fall ist, mache ich mir nicht den Stress, auch an den Clients Baustellen aufzureißen.

So, folgende Schritte habe ich zwischenzeitlich unternommen:
- Rechnerobjekt probeweise als Linux-Rechner und als Member-Server erstellt -> keine Änderung
- IP-Adresse in das Rechnerobjekt eingetragen und DNS-Forwardzone für seu-nappit-a.ad.example.de auf 192.168.10.12 eingetragen -> keine Änderung im Verhalten, aber klookup liefert jetzt den korrekten Hostnamen. Danke hierfür, mir war nicht klar, dass klookup nicht lokal auflöst sondern den DNS befragt.

Ich werde nun mal mit kclient weitermachen und sehen, ob das etwas hilft.

kclient mit kinit und smbadm join habe ich durch, alles wie gehabt. Oh mann....

univentionsupport · 12.09.2018

Was sind denn die Ausgaben bei der Benutzung von kclient?

martingo · 12.09.2018

Code:

root@seu-nappit-a:~# kclient

Starting client setup

---------------------------------------------------
Is this a client of a non-Solaris KDC ? [y/n]: n
        No action performed.
Do you want to use DNS for kerberos lookups ? [y/n]: n
        No action performed.
Enter the Kerberos realm: AD.EXAMPLE.DE
Specify the master KDCs for the above realm using a comma-separated list: seu-ucs-a.ad.example.de
Do you have any slave KDC(s) ? [y/n]: n
        No action performed.
Will this client need service keys ? [y/n]: n
        No action performed.
Is this client a member of a cluster that uses a logical host name ? [y/n]: n
        No action performed.
Do you have multiple domains/hosts to map to realm  ? AD.EXAMPLE.DE [y/n]: y
Enter a comma-separated list of domain/hosts
to map to the default realm: AD.EXAMPLE.DE

Setting up /etc/krb5/krb5.conf.

Do you plan on doing Kerberized nfs ? [y/n]: y
Do you want to update/add PAM per-service policy file(s) ? [y/n]: y
Enter a list of PAM service names in the following format: service:{first|only|optional}[,..]: first
Configuring PAM.

Do you want to copy over the master krb5.conf file ? [y/n]: n
        No action performed.

Note: /etc/krb5/krb5.keytab file not created, please refer to verify_ap_req_nofail in krb5.conf(5) for the implications.
Client will also not be able to host services that use Kerberos.

---------------------------------------------------
Setup COMPLETE.

root@seu-nappit-a:~#
root@seu-nappit-a:~# kinit Administrator@AD.EXAMPLE.DE
Password for Administrator@AD.EXAMPLE.DE:
kinit:  no ktkt_warnd warning possible
root@seu-nappit-a:~# klist
Ticket cache: FILE:/tmp/volatile-user/0/krb5cc_0
Default principal: Administrator@AD.EXAMPLE.DE

Valid starting     Expires            Service principal
09/12/18 14:10:46  09/13/18 00:10:46  krbtgt/AD.EXAMPLE.DE@AD.EXAMPLE.DE
        renew until 09/13/18 14:10:44
root@seu-nappit-a:~#
root@seu-nappit-a:~# ls /etc/krb5/krb5.keytab
/etc/krb5/krb5.keytab: No such file or directory
root@seu-nappit-a:~#
root@seu-nappit-a:~# smbadm join -u Administrator AD.EXAMPLE.DE
After joining AD.EXAMPLE.DE the smb service will be restarted automatically.
Would you like to continue? [no]: yes
Enter domain password:
Locating DC in AD.EXAMPLE.DE ... this may take a minute ...
Joining AD.EXAMPLE.DE ... this may take a minute ...
Computer account exists (CN=seu-nappit-a,CN=Computers,DC=ad,DC=example,DC=de)
Successfully joined AD.EXAMPLE.DE
root@seu-nappit-a:~#
root@seu-nappit-a:~# ls /etc/krb5/krb5.keytab
/etc/krb5/krb5.keytab
root@seu-nappit-a:~#
root@seu-nappit-a:~# ktutil
ktutil:  read_kt /etc/krb5/krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    8 host/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
   2    8 host/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
   3    8 host/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
   4    8 host/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
   5    8 host/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
   6    8 host/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
   7    8 host/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
   8    8         host/SEU-NAPPIT-A@AD.EXAMPLE.DE
   9    8         host/SEU-NAPPIT-A@AD.EXAMPLE.DE
  10    8         host/SEU-NAPPIT-A@AD.EXAMPLE.DE
  11    8         host/SEU-NAPPIT-A@AD.EXAMPLE.DE
  12    8         host/SEU-NAPPIT-A@AD.EXAMPLE.DE
  13    8         host/SEU-NAPPIT-A@AD.EXAMPLE.DE
  14    8         host/SEU-NAPPIT-A@AD.EXAMPLE.DE
  15    8 cifs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  16    8 cifs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  17    8 cifs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  18    8 cifs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  19    8 cifs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  20    8 cifs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  21    8 cifs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  22    8         cifs/SEU-NAPPIT-A@AD.EXAMPLE.DE
  23    8         cifs/SEU-NAPPIT-A@AD.EXAMPLE.DE
  24    8         cifs/SEU-NAPPIT-A@AD.EXAMPLE.DE
  25    8         cifs/SEU-NAPPIT-A@AD.EXAMPLE.DE
  26    8         cifs/SEU-NAPPIT-A@AD.EXAMPLE.DE
  27    8         cifs/SEU-NAPPIT-A@AD.EXAMPLE.DE
  28    8         cifs/SEU-NAPPIT-A@AD.EXAMPLE.DE
  29    8             SEU-NAPPIT-A$@AD.EXAMPLE.DE
  30    8             SEU-NAPPIT-A$@AD.EXAMPLE.DE
  31    8             SEU-NAPPIT-A$@AD.EXAMPLE.DE
  32    8             SEU-NAPPIT-A$@AD.EXAMPLE.DE
  33    8             SEU-NAPPIT-A$@AD.EXAMPLE.DE
  34    8             SEU-NAPPIT-A$@AD.EXAMPLE.DE
  35    8             SEU-NAPPIT-A$@AD.EXAMPLE.DE
  36    8 nfs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  37    8 nfs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  38    8 nfs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  39    8 nfs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  40    8 nfs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  41    8 nfs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  42    8 nfs/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  43    8 HTTP/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  44    8 HTTP/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  45    8 HTTP/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  46    8 HTTP/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  47    8 HTTP/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  48    8 HTTP/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  49    8 HTTP/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  50    8 root/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  51    8 root/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  52    8 root/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  53    8 root/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  54    8 root/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  55    8 root/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
  56    8 root/seu-nappit-a.ad.example.de@AD.EXAMPLE.DE
ktutil:  quit
root@seu-nappit-a:~#

univentionsupport · 14.09.2018

Na, aber das sieht doch alles gut aus!

Kannst Du jetzt von dem Solaris-System auf eingerichtete NFS-UCS-Freigaben zugreifen? Werden die Dateieigentümer dann auch namentlich (zB bei ls -l) angezeigt oder nur uid?

Was sagt jetzt getent passwd? Listet es da die UCS-AD Nutzer auf?

martingo · 17.09.2018

Ich habe den Versuch jetzt abgebrochen, mir geht die Zeit aus, ich brauche das System wieder.
Vielleicht versuche ich es später noch einmal, aber jetzt nutze ich Solaris erstmal ohne Domain.

Dennoch vielen lieben Dank für die viele zahlreiche Unterstützung.

gea · 17.09.2018

@/univentionsupport
Die entscheidende Frage bleibt damit unbeantwortet

Ist Solaris supportet/funktioniert - und zwar mit dem Solaris eigenen SMB Server (statt SAMBA)

martingo · 18.09.2018

Damit hast Du wohl recht, ich hätte auch gerne weiter dran gearbeitet, aber ich hatte keine Zeit mehr, brauche mein Produktivsystem wieder. Ein parallel aufgesetztes Solaris als kvm auf meinem Proxmox lief grottig langsam und die Solariszonen können nicht ohne weiteres alles, was man zum testen braucht.

Der Hauptauslöser für den DC war die Benutzerstruktur im AD, um damit nach einem Fileserver Crash, zügig die Freigaben wieder in Betrieb nehmen zu können. Das ist so definitiv nicht der Fall. Ich habe meine User jetzt in der Commandline angelegt mit festen uids und gids und kann das nach einer Neuinstallation als shell script in drei Minuten wieder aufsetzen.

An UCS liegt das Problem nicht, der Turnkey Samba DC hat wie gesagt die gleichen Probleme gemacht.

Neben der mangelnden Zeit zwei weitere Punkte wieso ich den Versuch auf Eis gelegt habe:
1. habe ich bisher überhaupt nichts zu den Fehlern in der Konsole herausgefunden, ich stochere so absolut im Trüben und tue irgendwas ohne wirklich dem Problem auf dem Grund zu gehen.
2. hängt mit erstens zusammen: ich arbeite seit fast zwanzig Jahren mit Linux. Wenn ich da Probleme habe, kann ich denen entweder gezielt auf den Grund gehen oder finde im Internet Lösungsansätze. Das ist bei Solaris völlig anders. Es gibt eine ellenlange Doku, die an vielen Stellen aber nichtssagend wird, wenn man sich nicht auf den absoluten Standard beschränkt und es gibt (zumindest im öffentlichen Bereich) sehr viel weniger Communityaustausch. Ich habe heute erst wieder (wegen irgendwas anderem) nach einer bimbeleinfachen Fehlermeldung gesucht (drei oder vier Worte in Anführungszeichen) und Google hatte wieder Mal null Treffer für mich.

besterino · 18.09.2018

Wäre mal interessant, ob/wie das mit einem "echten" Windows DC funktioniert. Normalerweise ist es bei Solaris ja so, wenn Oracle behauptet, dass es geht, dann geht es. So zumindest meine - sehr bescheidene und in keinster Weise repräsentative Erfahrung.

Und es kommt noch dazu, dass es in der Tat manchmal nicht so einfach herauszufinden ist, WIE es denn genau funktioniert.

Die Oracle Docu ist zwar eigentlich sehr gut, aber außerhalb der Oracle Docu findet man dafür echt wenig.

Solaris 11.4: Probleme als AD-Mitglied

Experte

Enthusiast

Experte

Urgestein

Experte

Urgestein

Experte

Urgestein

Experte

Enthusiast

Experte

Experte

Experte

Legende

Urgestein

Neuling

Experte

Neuling

Experte

Urgestein

Experte

Neuling

Experte

Neuling

Experte

Neuling

Experte

Urgestein

Experte

Legende