zahni

Da muss man nichts fummeln. Weißt Du was well known SID's sind?

Mitunter will man aber auch andere USB-Geräte anschließen. Manche BIOS-Versionen können die Geräte-Typen beschränken.

Die vordefinieren Konten und Gruppen bleiben auf Englisch. Das ist normal aber auch egal. Bei den "Kacheln": Eventuell sind da noch ein paar englische APP's installiert?

Unter der Voraussetzung, dass ein Router dazwischen ist und auf dem PC's ein Default-GW konfiguriert ist, kann PC2 an PC1 (der mit dem Subnet 255.255.0.0) erreichen. Ob die Back-Route funktioniert (also ein Antwort gesendet werden kann), bin ich mir nicht sicher. Wenn beide im gleichen Layer-2 Netz hängen ("am gleichen Switch"), sieht die Sache wie von mir geschrieben aus. Dann sind sie im gleichen Netz Die Subnet-Mask ist dann nicht relevant. Auch die IP-Adressen sind völlig egal, da die Adresse dann zu einem logischen Gebilde wird. PC1 schreit dann nur im LAN mit der Sprache "ARP": "Brauche MAC-Adresse für 1..2.3.4". 1.2.3.4 fühlt sich angesprochen und schreit seine MAC-Adresse zurück. Fortan können sich beide Ethernet-Frames senden. Wie ich schon schrieb, hat PC1 vermutlich eine Firewall eingeschaltet. Schau mal hier: http://de.wikipedia.org/wiki/Address_Resolution_Protocol Noch eine kleine Ergänzung: Denkbar wäre es, dass der IP-Stack von Windows IP-Adressen, die nicht zu seinem Subnet gehören, verwirft wenn kein Router konfiguriert. ist. Ob das so ist: K.A. Habe ich nie probiert.

Ist auf PC1 eine Firewall an? Dann wird u.U. ICMP blockiert.

Nun überlege noch mal. PC1 hat die Adresse 192.1.0.1 im Subnet 255.255.0.0 Du pingst 192.1.1.2 an. Diese Ping wird nicht über den Router geschickt, da der PC entscheidet, dass es sein lokales Netz ist. Der PC hinter einem Router, also in einem anderen Layer2-Netz, kann mit dieser Adresse niemals erreicht werden. Es würde z.B. funktionieren, wenn der die Adresse 192.2.1.2 hätte. Bei beide am gleichen Layer2-Netz hängen, sieht die Sache ein wenig anders aus. Dass wollte ich damit schreiben.

Der Client entscheidet in beiden Fällen, dass eine Zieladresse sich in seinem Netz befindet und er die Router in Ruhe gelassen werden kann. Dann kommt für Ziel-MAC-Adresse ARP ins Spiel. Hier fühlen sich dann auch alle passenden Geräte, völlig Subnet-Frei, angesprochen. . Probiere mal folgendes aus: 2 PC's, einer mit der IP-Adresse 192.1.1.1 und einer mit der Adresse 192.1.1.2 . Nun trägst Du auf beiden Geräten eine wahlfreie unterschiedliche Subnet-Mask ein. Das Default-GW bleibt leer (!). Können sich beide Geräte "Pingen"? Nun gibt Du beiden Geräten völlig unterschiedliche Adressen. Wieder ohne Default-GW. Können beide Geräte sich anpingen? Nun installierst Du mal Netmon oder Wiresharkk und verfolgst das ARP-Protokoll.

Wenn bei dem 1. Netz der Netz-Teil der Adresse 192.1. lautet, kann es dann eine Adresse 192.1.1.1 geben ? Kann es im Netz 192.1.1 eine Adresse 192.1.1.1 ? Wenn Du jetzt 2x ja ankreuzt, hast Du gewonnen ;). Netz-Maske ist nur dem jeweiligen Netzwerkgerät bekannt und dient nur dem korrekten Routing. Will sagen: Der Windows-PC entscheidet anhand der Netzmaske und seiner Routing-Table wohin er ein Pakt schickt. Und die Router machen das Gleiche.

Solche Lösungen werden in großen Unternehmen eingesetzt. Sicher kann man es nicht verhindern. Man kann es den Usern aber erschweren. Damit es immer wieder in Bewusstsein kommt, was man als User darf und was nicht. Sehr oft ist keine böse Absicht in der dem Tun der User, sondern eher Unwissenheit oder es ihnen egal. Gern werden von Usern so "Verfahren" erdacht, bei dem der IT-Abteilung die Fußnägel hochrollen - wenn sie davon wüsste. Bekannte Cloud-Dienste lassen sich über einen Proxy schon blockieren.

Der Proxy untersucht auch gepackte Dateien, keine Sorge. Verschlüsselte Archive lassen sich auch blockieren. Die Einschränkung ist HTTPS. Hier lassen sich nur ganze Hosts blockieren. Oder man lässt den HTTPS-Tunnel am Proxy enden und verwendet intern ein eigenes Zertifikat. Ist aber sehr problematisch und sollte eher nicht gemacht werden. Für den Rest hilft die SRP (sieh weiter oben). Malware wird eher selten über HTTPS mit gültigen Zertifikaten verteilt.

Zu 2. Einen Proxy mit Filter einsetzen. Es gibt Produkte, die solche Listen regelmäßig aktualisieren. Generell kann man mit einem Proxy den größten Teil der binären Downloads (EXE, JAR, etc) blockieren. Ein Produkt wäre http://www.mcafee.com/de/products/web-gateway.aspx

Click & Run streamt APP-V Pakete. Das wird mit dem WSUS nicht. Man kann die aber wohl Offline bereitstellen. Oder man installiert Office 2013 "richtig".

Eventuell filtert das VPN-Gateway ein paar Ports oder Protokolle.

Das ist nun wirklich vom System abhängig. Frage doch mal den Hersteller.

Dann macht ein WSUS Sinn. Und Du hast mehr Kontrolle über die Updates. Man könnte sie z.B. vorher testen ;)

Wenn Du einen WSUS-Server verwendest, bekommst Du alle Updates.

Wenn die Daten im AD gepflegt sind, würde ich mal prüfen, ob die die anderen Anwendungen an das AD anbinden lassen. Im einfachsten Fall geht das über LDAP. U.U. kann man dann in Kombination auch ein SSO-Verfahren über NTLM oder Kerberos einführen. PS: Als Referenz: http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-version-71/112880-cucm-8x-ldap.html

Schau mal hier: http://de.wikipedia.org/wiki/File_Transfer_Protocol Speziell die Unterschiede "Aktiv" und "Passiv" Bei Passiven FTP muss der Server dem Client die richtige (öffentliche) IP-Adresse übermitteln und nicht seine NAT-Adresse.

Ich verstehe immer nicht, warum Du den aktuellen Benutzernamen von der Datenbank wissen willst. Wenn Deine Web-Anwendung im Browser SSO macht (aktuell wage ich das zu bezweifeln), bekommt Deine Anwendung die Daten vom jeweiligen Webserver. Den SQL-Server kannst Du damit in Ruhe lassen. Es gibt in PHP auch irgendeine Funktion, mit der man alle Server-Variablen dumpen kann.

Manchmal stimmt die Kodierung bestimmter Sonderzeichen nicht, wenn man etwas per Copy&Paste von einer Webseite kopiert. Das sieht dann optisch korrekt aus. Es ist aber ein Unterschied, ob man ' , ` oder ´ benutzt ;)

Das sehe ich ein wenig anders. Bei BCS meldet man sich optimaler weise mit einem im Secure Store hinterlegten Konto bei einer externen Datenquelle an. Die Zugriffsrechte auf diesen BCS kann man dann im BCS konfigurieren. Bei einem Webservice mag das im Speziellen anders sein. Bei Datenbanken sollte man das aber eher vermeiden. Direkt durchgereichte Datenbank-Anmeldungen wurden schon oft zum Hacken von (DB)-Servern verwendet.

Auch wenn die Anwendung sich per Browser-SSO anmeldet, sollt diese Anmeldung nicht an den SQL-Server durchgereicht werden. Nur als Beispiel: SharePoint macht das auch nicht. So etwas kann eine erhebliche Sicherheitslücke öffnen. Speziell wenn die Anwendung auch eine alternative Anmeldemöglichkeit bietet. Sie Anwendung selbst kenne ich nicht. Normalerweise kann man aber bei Web-Anwendungen via SSO den Usernamen aus den Servervariablen extrahieren. Bei ASP (vbscript) wäre dies Request.ServerVariables("AUTH_USER")

Ich kann hier nur allgemein antworten: Bei PHP gehe ich mal von einer Web-Anwendung aus. Es ist ein ganz schlechtes Design, wenn ein User sich über ein Web-Frontend direkt auf einen Datenbankserver anmeldet. Hier sollte nach Möglichkeit immer mit technischen Usern gearbeitet werden, deren Konten nicht weiter bekannt sind. Zum Session-Sharing zwischen anderen Anwendungen gibt es genügend Lösungen. Man schreibt die (User).Daten aber nicht ein Cookie. Selbstverständlich ist das auch Abhängig von der konkreten Anwendung.

Hier kann er doch weiterhüpfen: ;)

Am Einfachsten in der windowsupdate.log