Logonscript mit Recht in ADS zu schreiben

[Scrummel 0]

Hallo Zusammen,

 

ich versuche folgendes Logon-Script (ist noch Testweise) bei einem Login via Cisco-Client auszuführen.

Der Cisco Client startet netterweise ein bestimmtes Skript, wenn man sich per VPN anmeldet.

 

Hintergrund ist, dass ich beim Anmelden gerne bestimmte Infos vom User und der Hardware in die Beschreibung des Computers Objectes im ADS reinschreiben möchte.

Das Skript mit Admin-Rechten läuft, ich habe es im Netz irgendwo gefunden und geringfügig für mich angepasst.

 

Jetzt kommt aber das Problem, dass der Cisco Client wahrscheinlich mit den normalen Userrechten startet und somit natürlich kein Eintrag ins ADS erlaubt ist. Es kommt die Fehlermeldung "Zugriff verweigert" Code 80070005, Quelle Active Directory.

 

Gibt es hier irgendeine Lösung für mich? Ein Starten als runas usw. ist ja nicht möglich, da dann dieser User im Beschreibungsfeld landet.

 

Bin für jeden Tipp dankbar.

 

Bis dann,

Scrummel

Set WshNetwork = WScript.CreateObject("WScript.Network")
Set objFSO = WScript.CreateObject("Scripting.FileSystemObject")
Set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set wshShell	= WScript.CreateObject("WScript.Shell" )

For Each objSMBIOS in objWMI.ExecQuery("Select * from Win32_SystemEnclosure")
serviceTag = replace(objSMBIOS.SerialNumber, ",", ".")
manufacturer = replace(objSMBIOS.Manufacturer, ",", ".")
Next

For Each objComputer in objWMI.ExecQuery("Select * from Win32_ComputerSystem")
model = trim(replace(objComputer.Model, ",", "."))
Next

Set objTextFile = objFSO.OpenTextFile("D:\logon.txt", 8, True)
objTextFile.WriteLine(date & "," & time & "," & WshNetwork.UserName & "," & WshNetwork.ComputerName & "," & wshNetwork.UserDomain & "," & serviceTag & "," & manufacturer & "," & model)
objTextFile.Close

Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)

if NOT objComputer.Description = WshNetwork.UserName & " (" & serviceTag & " - " & manufacturer & " " & model & ")" then
objComputer.Description = WshNetwork.UserName & " (" & date & " um " & time & " | " & WshNetwork.ComputerName & "," & wshNetwork.UserDomain & " | " & serviceTag & " - " & manufacturer & " " & model & ")"
objComputer.SetInfo
end if
strMsg=serviceTag & VbCrLf & manufacturer & VbCrLf & model

WshShell.PopUp strMsg,15,"  "&strCompany,64

[tesso 375]

Ich halte dein Vorhaben für sicherheitstechnisch sehr bedenklich.

 

Warum soll ein User auf das AD Objekt schreiben dürfen?

Willst du ernsthaft ein Userskript als Admin ausführen? Dann ist der User sehr schnell Admin.

[Scrummel 0]

Ich halte dein Vorhaben für sicherheitstechnisch sehr bedenklich.

 

Warum soll ein User auf das AD Objekt schreiben dürfen?

Willst du ernsthaft ein Userskript als Admin ausführen? Dann ist der User sehr schnell Admin.

Nein, natürlich nicht. Deshalb ja meine Frage. Der eigentliche Wunsch ist wie gesagt, dass ich die Infos in das Feld rein bekomme.

Da das Skript irgendwer mal in der Vergangenheit geschrieben hatte, muss derjenige es ja auch irgendwie eingesetzt haben.

Nun hoffe ich auf irgendeinen Kniff, wie ich nur das Bemerken Feld auch mit Bordmitteln als User füllen kann.

 

Wie geschrieben, managed der Cisco Client alles. Der startet das Skript. In vbs wird ja die impersonate Funktion verwendet. Ich frage mich also, ob ich hier den objComputer.SetInfo Aufruf verwenden kann.

[NilsK 2.934]

Moin,

 

mal abgesehen von der Frage, ob das Gesamtvorgehen so sinnvoll ist* - du kannst das Cisco-Servicekonto in eine Gruppe stecken und dieser Gruppe gezielt Schreibrechte auf die relevanten Attribute geben.

 

* grundsätzlicher Einwand an der Stelle: Das AD ist keine Inventardatenbank.

 

Gruß, Nils

[MurdocX 949]

Möglichkeiten in das AD des Benutzers zu schreiben gibt es, sogar einige. Eine Liste der Attribute habe ich unten aufgelistet.

 

Wäre es denn nicht sinniger und einfacher ein - immer diese Powershell ;-) - Skript zu schreiben welches die Information in eine einfache Textdatei einer versteckte Freigabe packt? Ich finde schon. Admin-Zugriff ist nicht nötig, das AD wird nicht zugemüllt und zu guter letzt, kannst du die Freigabe granular berechtigen.

 

Benuter-Attribute durch den Benutzer beschreibbar:

• streetAddress
• homePostalAddress
• assistant
• info
• country/region name
• facsimileTelephoneNumber (fax number)
• International-ISDN-Number
• Locality-Name
• MSMQ-Digests
• mSMQSignCertificates
• Personal-Title
• Phone-Fax-Other
• Phone-Home-Other
• Phone-Home-Primary
• otherIpPhone
• ipPhonenumber
• primaryInternationalISDNNumber Phone-ISDN-Primary
• Phone-Mobile-Other (otherMobile)
• Phone-Mobile-Primary
• Phone-Office-Other (otherTelephone)
• Phone-Pager-Other
• Phone-Pager-Primary
• physicalDeliveryOfficeName
• thumbnailPhoto (Picture)
• postalCode
• preferredDeliveryMethod
• registeredAddress
• State-Or-Province-Name
• Street-Address
• telephoneNumber
• teletexTerminalIdentifier
• telexNumber
• primaryTelexNumber
• userCert
• User-Shared-Folder
• User-Shared-Folder-Other
• userSMIMECertificate
• x121Address
• X509-Cert

Hier noch ein kleiner Anreiz meinerseits: 

#// Model
[String]$Model = Get-ItemProperty -Path HKLM:\HARDWARE\DESCRIPTION\System\BIOS -Name 'SystemProductName'  | Select-Object -ExpandProperty 'SystemProductName'

#// BIOS-Hersteller
[String]$BiosHersteller = Get-ItemProperty -Path HKLM:\HARDWARE\DESCRIPTION\System\BIOS -Name 'SystemManufacturer'  | Select-Object -ExpandProperty 'SystemManufacturer'
 
#// BIOS-Version
[String]$BiosVersion = Get-ItemProperty -Path HKLM:\HARDWARE\DESCRIPTION\System\BIOS -Name 'BIOSVersion' | Select-Object -ExpandProperty 'BIOSVersion'

#// Computername
[String]$PCName = $env:COMPUTERNAME

#// Benutzername
[String]$Benutzername = $env:USERNAME

bearbeitet 19. Januar 2017 von MurdocX

[NilsK 2.934]

Moin,

 

Benuter-Attribute durch den Benutzer beschreibbar:

 

er möchte ja ins Computerobjekt schreiben ... also entweder Berechtigungen setzen oder - was ich auch andeuten wollte - die Daten in einer separaten Datenbank ablegen.

 

Gruß, Nils

[MurdocX 949]

oder - was ich auch andeuten wollte - die Daten in einer separaten Datenbank ablegen.

 

Halte ich auch für die sinnvollste Lösung. Ich verwalte z.B. über dieses Verfahren eine kleine Inventarisierungslösung für ca. 500 Computer. 

[PowerShellAdmin 169]

Unabhängig von der Sinnigkeit, ist das ja kein komplexes Design erforderlich.

Daten in einer kleinen DB einpflegen oder entsprechende Worker-Items und bei Bedarf dann von einem Server weiter verarbeiten und ins Ad-Objekt schreiben.

 

Aber letztere dürfte dann auch hinfällig sein.

bearbeitet 19. Januar 2017 von PowerShellAdmin

[Scrummel 0]

Moin,

 

mal abgesehen von der Frage, ob das Gesamtvorgehen so sinnvoll ist* - du kannst das Cisco-Servicekonto in eine Gruppe stecken und dieser Gruppe gezielt Schreibrechte auf die relevanten Attribute geben.

 

* grundsätzlicher Einwand an der Stelle: Das AD ist keine Inventardatenbank.

 

Gruß, Nils

 

Also erst mal vielen Dank!. Jedoch startet wohl der Client nicht mit dem Service-Konto, das muss ich mir noch etrwas genauer anschauen. Das hatte ich bereits probiert.

 

Warum stellst Du das Gesamtvorgehen aber in Frage? Oder unterstellst mir, dass ich die AD als Inventardatenbank verwenden möchte? Ich seid einfach zu sehr Fachblind.

So richtig hat keiner meine Frage beantwortet, dafür bekommt man aber etliche Antworten das alles nicht clever sei. In Eurem Blickwinkel vielleicht, aber da kommt zu sehr die Vorverurteilung.

Warum macht man das immer?

Da fragt man nach einer Situation A und bekommt Hinweise auf Unsinnigkeiten (ohne den gesamten Kontext zu kennen, der nicht immer notwendig ist) und auf Lösungen B, C, D und E.

Wenn man die Frage nicht  beantworten kann, kann man auch einfach mal nichts antworten, anstelle das Vorhaben des Anderen als fragwürdig und unsinnig zu erachten.

 

Manchmal möchte man einfach nur eine Aufgabe gelöst bekommen. Aber Schwupps, hagelt es wieder Vorschläge, das die Variablen falsch sein oder ein anderer Rechenweg besser sei.

 

So zum Hintergrund: Es gibt in der AD ein Bemerkungsfeld. Darf ich bitte darin reinschreiben, was ich möchte, ja? Ist das möglich?

Und die Infos, die da via Loginscript rein sollten, dienen nur der schnellen und einfachen Übersicht für eine bestimmte Person, damit diese nicht immer noch das Inventarisierungsprogramm oder Verteilungsprogramm öffnen muss. Für die schnelle Info zwischendurch also.

Und da einige dieser Skripte so im Netz rumfliegen, kann der Wunsch ja nicht ganz so befremdlich sein. Das ganze funktionert ja auch problemlos als standard Loginskript.

Ich hoffte, dass ich den Cisco Client auch mit diesem Konto irgendwie starten kann.

 

Hier die Bitte an euch: wenn jemand Orangen mag, ihr aber nicht, dann ist das okay. Aber demjenigen dann gleich seine Befremdlichkeit klar machen zu wollen, gehört sich einfach nicht.

Ich möchte euch hiermit einfach aufzeigen, dass ihr manchmal ganz schön veruteilend seid. Da ist das Ego doch manchmal schneller als die Vernunft.

Klar, der naheliegende Gedanke ist, dass ich Eure Meinung aushalten muss, so wie ich meine hier gerade kund tue.

Der Unterschied: Ich reagiere auf eure Meinung, die hier einfach fehl am Platze ist.

 

Und falls es das Ego zulässt, fragt Euch, warum ich mir hier die Zeit für diese Zeilen nehme.

 

Danke für die Zeit, die Ihr euch genommen habt.

Scrum

[NilsK 2.934]

Moin,

 

ich glaube, du hast ein Problem. Kannst du gern haben, aber lass mich damit in Ruhe.

 

Oder wie man in den Newsgroups sagte: Plonk.

 

Gruß, Nils

[tesso 375]

Ich bin raus. Viel Spaß beim rumfrickeln.

[Dr.Melzer 191]

@scrummel:

 

Bitte atme einmal tief durch, frage dich ob die Ratschläge die dir gegeben wurde für das Erreichen deiner Ziele helfen und dene darüber nach ob es zielführend ist die Leute anzugreifen, von denen du dir Hilfe erwartest.

 

@all:

Bleibt bitte freundlich und sachlich.

[PowerShellAdmin 169]

 

Und falls es das Ego zulässt, fragt Euch, warum ich mir hier die Zeit für diese Zeilen nehme.

 

Danke für die Zeit, die Ihr euch genommen habt.

Scrum

 

Unabhängig von der Sinnigkeit, ist das ja kein komplexes Design erforderlich.

Daten in einer kleinen DB einpflegen oder entsprechende Worker-Items und bei Bedarf dann von einem Server weiter verarbeiten und ins Ad-Objekt schreiben.

 

Aber letztere dürfte dann auch hinfällig sein.

 

Warum setzt du deine Zeit nicht konstruktiv ein....

 

Ich würde hier clientseitig eine kleine Datenbank erstellen und eintragen oder pro Vorgang ein XML Files erzeugen und diese dann serverseitig verarbeiten und die Trennung der Berechtigungen schön lassen wie sie sind.

Und ja an der Stelle kann es auch sinnvoll sein, dass man auf das "Reporting" via AD verzichtet und z.B. einfach einen MS SQL Report baut usw... gibt ja genügend Möglichkeiten.

 

Die Aufgabe eines IT Consultant ist es nicht, stumpf Kundenanforderungen abzuarbeiten, sondern diese auch sinnvoll umzusetzen, also auch das Anliegen zu hinterfragen.

 

bearbeitet 23. Januar 2017 von PowerShellAdmin