hoki

Hallo Nils. Danke für die schnelle Antwort. Also braucht wirklich jeder Server, an dem sich User einer getrusteten Domäne anmelden wollen, auch die Möglichkeit mit der getrusteten Domäne kommunizieren zu können? Dann ist meine Vorstellung gänzlich falsch. Ich konnte mir das auch wegen dem enormen Aufwand denn man dann hat nicht vorstellen. Hat jemand ein Ablaufdiagramm zur Hand in der die Authentifizierungsschritte chronoligisch aufgelistet werden. Google liefert bei Vertrauensstellungen zuviele hits... hoki ----- PS: Ergänzung -< welche Ports wären das denn. Sind das die gleichen die auch für Vertrauensstellungen zwischen 2 Domänen gelten oder kann ich auf einige Dienste verzichten. Nur Kerberos und LDAP wird ja vermutlich nicht reichen.

Hallo MCSE Board. Ein AD Problem lässt mir im Moment keine Ruhe. Habe hier leider kein Visio, muss es euch deshalb beschreiben. Ich habe einen Server A, dieser steht in einer durch FiWa abgeschotteten IDC. Es exisiteren (unter anderem) Freischaltungen in Richtung einer Domäne B. In dieser ist der Server Memberserver, man kann sich auch anmelden, alles prima und wunderbar. Domäne B hat einen Trust zu Domäne C. Man hat nun eine Gruppe aus Domäne C den lokalen Administratoren des Servers hinzugefügt, es gibt auch Freischaltungen für RDP von Workstations aus Domäne C in Richtung des Servers. Bis zur Konsole kommt man wunderbar, nur anmelden kann man sich nicht, Fehler "specified domain ... coult not be contacted". Das die Domäne nicht kontaktiert werden kann ist klar, die FiWa sitzt dazwischen. Aber muss Sie überhaupt direkt kontaktiert werden? Meine Vorstellung war immer, das die Authehtifizierung über den eigenen DC läuft? Ich melde mich mit meinen crendentials von Domäne C an, der Memberserver reicht Sie weiter an seinen DC und der handelt alles weitere mit dem DC der getrusteten Domäne aus. Muss ich wirklich für jede getrustete Domäne und jeden Server Freischaltungen durchführen? hoki

Wenn S!nky keine hat, ich hätte welche ;-) Wie verhält sich das ganze denn in einem Multi-Domänen Forrest. Eine Root Domäne mit 3 Child Domänen, die CA soll in einer der drei Child Domänen eingerichtet werden. Hintergund: Einsatz von LDAPs in der Child-Domain. Ich überlege jetzt, welchen Einfluss diese CA im ungünstigstem Fall auf die beiden anderen Child Domänen bzw. auf die Root Domäne haben kann. alex

Evtl. durch eine GPO geblockt?

Hallo. Nein, Secure Email o.ä Anwendungen (ILO`s ans AD binden etc) möchten wir nicht umsetzen. Es geht rein um die Möglichkeit LDAP Abfragen zu verschlüsseln, so das dieser Traffic (der ansonsten ja im Klartext über das Netz geht) ansatzweise geschützt ist/wird. Das es dann damit nicht getan ist, ist klar. Erscheint aber für den Anfang aber mehr als Sinnvoll. Wie gesagt, die PKI Dokumentation ist recht, ähhh, trocken. Deswegen stehe ich bei diesem Thema ja so auf dem Schlauch. Ich kann wirklich nicht Einschätzen welche Aufwände dort entstehen, vorallem weil es in dem geposteten KB so simpel erscheint. Wenn es so ist, um so besser. Aber da ich es nicht nachlesen kann muss ich auf eure Erfahrungen hoffen. Und da insbesondere nochmal mit dem Hinweis auf den Multi-Domain Forrest. hoki

Hallo Board. Wir möchten in unserer Domäne SSL verschlüsselte LDAP Abfragen ermöglichen. In unserem Fall würde ein Zertifikat eines Drittanbieters reichen. Und von MS gibt es dazu auch einen passenden Kb Eintrag, nämlich diesen; How to enable LDAP over SSL with a third-party certification authority ABER, ist das wirklich schon alles (abgesehen davon beim Zertifikat die richtigen Infos anzugeben) ? Muss ich mich nicht um die Schlüsselverwaltung kümmern etc.? Ich habe hier auch das offizielle PKI Buch von MS, das hilft mir aber auch nicht wirklich weiter. Reicht es denn wirklich aus den beschriebenen Weg auf einem DC auszuführen? Desweiteren haben wir einen Multi-Domänen Forrest. Wirkt sich eine solche Änderung wirklich nur auf die einzelne Domäne aus, oder folgern daraus auch Änderungen für alle Domänen im Forrest? Evtl. hat da jemand von euch Felderfahrung und kann da Tips geben die auch normalsterbliche verstehen ;) Die PKI Dokumente von MS sind wirklich starker Tobak. gruß hoki

Spiele schön und gut. Aber wenn man mal 3 VMs auf einmal laufen lassen möchte, dann ist ein Quad natürlich besser ;-)

Ja ich weiß, das ist ein exotisches Problem, aber hat denn wirklich niemand auch nur eine Idee?

Ja; - war vorher eingebunden - taucht in der Datenträgerverwaltung korrekt auf. Und ich kann wie gesagt auch auf die Daten (die ich nicht verlieren möchte und darf) zugreifen, aber wie gesagt nur, wenn ich den Datenträger mit dem explorer öffne. Ich habe auch versucht nach dieser Art von "Fehler" zu googeln, konnte aber nichts passendes finden. Ist mir wie gesagt ein absolutes Rätsel.

Hallo MCSEler. Hier ein eher privates Problem. Ich muss den Computer eines Bekannten neu aufsetzen. Dieser hat 2 Platten eigebaut. Nach der Installation wird nun die zweite Platte zwar angezeigt "zusätzlicher Datenträger", sie hat aber kein Festplattensymbol. Das alleine wäre trivial, wenn ich aber per Doppelklick versuche zuzugreifen, startet der Netzwerkinstallations-Assistent (!!!). Per rechtsklick -> explorer lässt sich allerdings einwandfrei auf die Platte zugreifen. Ist mir ein absolutes Rätsel. Die Platte ist NTFS formatiert, nicht verschlüsselt, nicht komprimiert oder sonstiges. Alles so wie es sein sollte. Liegen auf der 2ten Platte evtl noch irgendwelche "altlasten" in Dateiform, die das neu aufgesetzte System verwirren? Einen Call kann ich da schlecht aufmachen ;-) Evtl. weiss jemand von euch Rat.

Naja, eine stand-alone maschine kann in gewisser Hinsicht durchaus sicherer sein. Steht der Server in einer Domäne, haben alle Domänen Administratoren Zugriff, bzw können sich Zugriff verschaffen. Gerade in größeren Firmen gibt es durchauss mal mehrere Personen mit den nötigen Rechten. Und auch wenn man gerade seinen Domänen Admins trauen muss, kann es doch formale Gründe geben dieses Riskio zu minimieren (PCI Zertifizierung etc.). Ein standalone Server, physikalisch gut weggeschlossen, hat nur einen lokalen Benutzer, und für den kann man dann das Passwort in 2 Teile aufteilen (4 Augen Prinzip). Ist aber wie gesagt alles nur für den Fall einer absolut extremen politischen Anforderung, hat jetzt mit dem technischen Problem von Dave nichts zu tun.

Ich vermute blub meint diese scriptsammlung: http://www.jsifaq.com/SF/Tips/Tip.aspx?id=8451 Passwörter haben in dieser Domäne per (Sicherheits)Design ein max. Alter von 42 Tagen. Nach Ablauf dieser 42 Tage ist das PW nicht mehr gültig, der User kann sich nichtmehr anmelden und das PW entsprechend auch nicht mehr ändern. Es würde/wird dann vom Helpdesk zurückgesetzt bzw. neu vergeben.

Age of Empires ist ja nen Microsoft Produkt, das ist doch dann automatisch "Standardsoftware" ;)

Die User dürfen Ihr Passwort selber setzen, aber nur solange es nicht abgelaufen ist. Und wenn man nicht bemerkt das dass eigene PW in kürze abläuft, dann hat man diese Möglichkeit irgendwann nicht mehr und der HelpDesk muss ran. Dein Tip bezieht sich auf das Script: "8451 » Email a password expiration notice to all users whose password will expire in n days. 09-Sep-04"? Url darf ich hier ja vermutlich nicht posten.

Ahoi MCSEler. Ich habe einige Domänen bei denen sich die User eher selten einloggen. Das baldige Ablaufen des Passwortes fällt so evtl. garnicht auf. Sollte ein User des Nächtens dann doch auf die Idee kommen arbeiten zu wollen, dann müsste bei uns die Bereitschaft auf dem Bett geklingelt werden um das PW zu resetten. Das ist natürlich unschön. Ich suche also nach einer Möglicheit, n-Tage vor Ablauf des PWs, eine Mail an den User abzusetzen. Die Boardsuche (http://www.mcseboard.de/windows-forum-ms-backoffice-31/user-per-mail-warnen-passwort-ablaeuft-60775.html) führt zu einem Beitrag der allerdings schon reichtlich alt und für w2k erstellt wurde. Ich habe mir das Tool aus dem Ressourcekit mal angesehen, kann es aber nicht zur Kooperation bewegen. Bei Mircosoft findet sich garnichtsmehr darüber. Kann mir jemand eine aktuelle Lösung hierzu empfehlen, am besten natürlich noch hoch offiziell und Kinderleicht zu implementieren?

Jo, die B1 passt auch technisch nicht, ist "nur" PCI. Ein neues Riserboard ist ohnehin verbaut. Wollte auch nur nochmal Feedback geben, die Eicon Karte ist inzwischen da und passt auch rein. War ich wohl doch zu Misstrauisch. Danke für eure Tipps.

Jo. Thx für die schnellen Antworten. Die AVM B1 liegt bei mir auf dem Schreibtisch. Die Passt definitiv nicht. Abgesehen davon dass die kein PCI-X unterstützt, die ist wie gesagt zu kurz. Und von den Bildern her ist die Eicon Karte genauso groß oder (eben klein). Die C2 und C4 werden nicht mehr hergestellt und sind auch nicht mehr verfügbar. Ich werde euren Rat beherzigen und mir mal eine Eicon Karte besorgen. Versuch macht Kluch.

Ahoi MCSEler. Folgendes Problem; ich brauche eine ISDN Karte, diese muss 3 Bedingungen erfüllen; 1. CAPI 2.0 fähig sein 2. PCI-X oder PCI-Express Schnittstelle haben 3. In einen DL380 G 4/5 passen. Das Ding ist nämlich folgendes, in den HP Servern dieses Typs passen eigentlich "kleine" PCI-X Karten nicht hinein. Die Karten passen zwar in den Slot, sind aber zu kurz und schliessen nicht mit dem Ende des Riser Käfigs ab. Man könnte zwar das Slotblech abmachen, aber dann schlackert die Karte mehr oder weniger lose im riser cage rum, das kanns ja nicht sein. Bei einer PCI-E Karte würde ich mal davon ausgehen dass es immer passt. Die Diva Server BRI bzw. Diva Server V-BRI würde von den Leistungsmerkmalen her passen, nur ob Sie von der Bauform her in den Server passen ist die Frage. Setzt jemand von euch evtl. eine dieser Karten in seinen Servern ein bzw. kann mir jemand einen Hersteller empfehlen der entsprechende Serverprodukte (in der passenden Bauform) anbietet? Ich hab z.B. das Gefühl das AVM noch nie einen richtigen Server gesehen hat. Die verkaufen noch normale PCI Karten als "Serverprodukt".

Ich meine mich an einen Webcast von Daniel Melanchton erinnern zu können, der davon sprach, es könnte bei GPOs zu Problemen kommen wenn man da mit verschiedenen Sprachen tüdelt. Aus diesem Grunde sähen die GPO Templates bei Longhorn dann auch grundlegend anders aus. Aber da ich kein MCSE bin halte ich mich am besten einfach bedeckt ;)

Es könnte zu Problemen kommen wenn man mit der englischen Version die deutschen GPOs bearbeiten möchte (und im zweifelsfall umgekehrt). Ansonsten sollte das eigentlich egal sein....

Kurze Zwischenfrage; Warum sollte es keinen Sinn machen auf das OS auf ein Raid1 zu legen?

Wenn es "Nur" um Password Self Service geht, dann solltest du dir auch den Password Manager von Quest (Tools for Database, Application & Windows Management — Quest Software) ansehen. Wenn deine User mehr machen sollen/dürfen, z.B. in bestimmen OUs Gruppen erstellen und verwalten, dann gibt es von Tools4ever noch UMRA. Da kannst du aus einem Baukastensystem eine Oberfläche zusammenklickern mit denen man dann im Grunde alles machen kann was auch die MMC bietet. Nur eben simpel gehalten für den Endanwender.

Ich habe ein fast identisches Problem. Nur dass sich der user nicht in einer anderen subdomain anmelden muss, sondern in einer anderen trusted domain. Gibt es inzwischen etwas neues in dieser Angelegenheit?

So eine SBS Lizenz kostet ja auch ein bisschen was, warum nimmst du nicht ein w2k std. wenn der nur so wenig leisten muss?

Ahjo, dann passte das ja doch. Erstmal einen heissen Dank für die Antworten. Muss ich doch mal ein bisschen Intensiver im Netz suchen, konnte da partout keine Empfehlungen finden. Aber das Ergebniss eurer Erfahrungen ist ja offenbar mehr als eindeutig.