sbE

super...danke! falls noch jemand diesen thread findet...hier gibt es weiterführende infos: You cannot connect to an 802.1X wired network after you upgrade to Windows XP Service Pack 3 dort findet man auch einen weiterführenden link bezüglich den änderungen zu AuthMode und Supplicantmode (wird nun nicht mehr über die registry gesetzt).

hallo, bei einer vielzahl unserer systeme ist der karteireiter "authentifizierung" (eigenschaften lan-verbindung) verschwunden. dort werden die 802.1x-einstellungen geregelt...somit haben wir nun das problem, dass sich diese system nicht mehr über 802.1x authentifizieren können. am switch selbst kommt auch keine 802.1x-anfrage mehr an...von daher liegt die vermutung nahe, dass dieser umstand über einen xp-update. vor tag x (ist vielleicht ein paar wochen her) lief die 802.1x-geschichte hervorragend. vielleicht hat jemand einen tipp für mich?

hmm, flow control...ist ne idee. auf einem hp-switch ist das defaultmäßig deaktiviert. ich schreib's mir mal hinter die ohren. weiß jemand zufällig wie sich die tcp-window geschichte unter 2003 verhält!? wird das window während einer session automatisch nach oben geregelt!?

naja, so einfach ist das mit der testerei nicht...da kundensystem(e) und dann auch noch jeweils exchange & ads. :( die stats der switchports sind sauber und ein mode-mismatch ist's auch nicht. da die server von dell und hp sind, und dann auch noch eine generation dazwischen liegt haben wir also auch nicht die selbe ausgangslage was die nic-treiber angeht. da muß irgendwie irgendwo eine andere gemeinsamkeit existieren. mehr server habe ich übrigens noch nicht getestet (aus zeitgründen). im einsatz ist übrigens ca antivirus.

hi, ich habe hier ein problem mit mehreren servern. wenn ich daten von diesen auf z.b. mein notebook kopieren möchte, dauert dies extrem lang (5 gb in 10 stunden). wenn ich aber daten von einem anderen pc au mein notebook (am gleichen switch wohlgemerkt) kopiere, flutscht das wie erwartet. mit iperf läßt sich das kuriose verhalten noch besser darstellen: C:\>iperf -c server1 ------------------------------------------------------------ Client connecting to server1, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [ 3] local nb1 port 49359 connected with server1 port 5001 [ 3] 0.0-10.0 sec 1.56 MBytes 1.31 Mbits/sec C:\>iperf -c pc1 ------------------------------------------------------------ Client connecting to pc1, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [ 3] local nb1 port 49380 connected with pc1 port 5001 [ 3] 0.0-10.0 sec 139 MBytes 117 Mbits/sec jetzt das interessante... sobald ich das tcp-window auf mindestens 9kb hochsetze, explodiert die übertragungsrate förmlich auf das zu erwartende normalniveau: C:\>iperf -c server1 -w 9k ------------------------------------------------------------ Client connecting to 172.16.1.3, TCP port 5001 TCP window size: 9.00 KByte ------------------------------------------------------------ [ 3] local pc1 port 49366 connected with server1 port 5001 [ 3] 0.0-10.0 sec 426 MBytes 358 Mbits/sec tja, wie schon gesagt, dass problem tritt nicht nur mit einem server auf. was kann das wohl sein!?!?!?! windows bug? böser virenscanner!!?!? schlechte treiber (sind aber unterschiedliche netzwerkkarten (hp/dell)?!?

danke dir, der link ist wirklich hilfreich!

hi, kann mir jemand die ip-ports nennen, die bei einer anmeldung an einem active directory gebraucht werden (also für loginscript, laufwerksmapping etc)? hintergrund ist eine beschränkung der maschinenauthentifizierung im wlan. vielen dank schonmal

Hallo, ich habe eine LAN-Umgebung mit 802.1x-Auhentifizerung per PEAP(MS-CHAPv2) und dynamischen VLANs (zugewiesen per Radius-Attribut via IAS). Alles funktioniert soweit bestens. Nur manchmal erhält ein User, der per Radius-Attribut sein VLAN zugewiesen bekommt (bzw. der Switch dahinter), kein Home-Laufwerk gemappt. Meldet sich der User dann kurz ab und wieder an, bekommt er es auch. Irgendwann klappt es dann auch immer...also inkl reboot. Der IAS fragt Computerkonto und Benutzerkonto in der ADS ab und das Häkchen beim Client "als Computer authentifizieren, wenn Computerinformationen verfügbar" ist gesetzt. Übrigens funktioniert das mappen problemlos, wenn ich die VLAN-Zuweisung per IAS "weglasse"...also eine ganz normale 802.1x-Authentifizierung durchführe. Irgendwie klingt das nach einem Timingproblem. Hat jemand eine Idee wie ich das Lösen könnte!?

eine unternehmenszertifizierungsstelle ist es...aber vielleicht kann ja noch jemand auf praxiserfahrungen zurückgreifen. die suche per google und bei microsoft bringt irgendwie überhaupt nichts brauchbares. :( oder vielleicht muß ich doch mal eine testumgebung aufbauen und die systemzeiten ein jahr vorsetzen...das müßte doch eigentlich auch klappen.

hallo, das verhalten der zertifizierungsstelle unter windows 2003 standard ist ja weniger konfigurierbar als bei der enterprise oder datacenter edition. was passiert nun genau, wenn ein benutzer- oder computerzertifikat ausläuft und erneuert werden muß? wird dies automatisch erneuert (erneuerungszeitraum unveränderbar auf 6 wochen) oder muß man an jedem client hand anlegen?

super...ich danke dir. ich werd's mal testen.

@darking das klingt gar nicht mal so schlecht..."track interface xyz"... nur weiß ich aus dem stehgreif gar nicht wie ich mit dem ciscos so einen tunnel realisiere. hast du vielleicht kurzer hand einen link für mich? cisco benutzt ja meist irgendwelche berzeichnungen, die ohne ahnung des syntax (oder eines teils davon) schwerlich zu finden sind.

habe ich probiert - funzt leider nicht. 1. route über eth0 zu vpn-router ins web 2. route über bri0 wenn ich nun den vpn-router vom internet trenne macht der 1600er gar nix. der ping der workstation geht ins leere und der 1600er denkt gar nicht daran die zweite route zu "probieren". ziehe ich aber das lan-kabel des 1600 (eth0 down) springt die 2. route an und baut eine isdn-verbindung auf. aber das soll ja nicht ziel der übung sein.

nein, leider auch nicht. also so wie ich das sehe, habe ich ohne den einsatz eines routingprotokolls keine möglichkeit mit statischen mitteln ein isdn-backup zu fahren (wenn man davon ausgeht, das der 1600er selbst nicht das interface hat, welches ins internet geht und ein backup bekommen soll). 1600: - int eth0 ---- lan (mit vpn-router ---- internet) - int bri0 ---- isdn backup

eieiei, mir deucht ich habe ein problem! im cisco feature navigator tauchen die features "Reliable Static Routing Back-up using Object Tracking" oder "FHRP" nicht für den 1600er auf. also ich glaube da hilft mir auch kein t-release mehr. :( *seufz*