Zugriff auf Global Collection unter Windows 7

[Lsteinme]

Hallo, bisher hat folgender Code immer funktioniert und mir den korrekten Pfad zu meiner GC geliefert:

'Nach dem Connection String suchen

        Dim oCont As Object = GetObject("GC:")

        For Each gc As Object In oCont

           gcPath = gc.ADsPath

        Next

Versuche ich das ganze nun aber unter Windows 7 auf einem Server, so bekomme ich immer ein leeres gcPath Objekt/String raus. Wie man sicher sicher denken kann, will ich später auch was aus der GC auslesen, wegen ich den Pfad brauche.

Ich hab auch versucht einfach mal den String fix vorzugeben, auch das funktioniert im Serverkontext nicht, bzw ich bekomme eine "Network path not found" Com-Exception zurück wenn icher später versuche den Pfad zum abruf von Daten zu verwenden.

Was jedoch funktioniert ist das ganze auf einer lokalen Rechner internen Festplatte laufen zu lassen. hier funktioniert alles wie bisher gewohnt. Ebenso funktioniert das gleiche Prozedere, mit dem Absolut gleichen Code, wenn man es von einem W-XP Rechner aus an startet ohne Probleme.

Woran kann dieses verhalten liegen? wurde da von Windows XP zu Windows 7 irgendwas geändert in Sachen Zugriff auf die GC? Oder liegt da ehr beim Server was im argen?

Hoffe jemand weiß da Rat,

gruß Lucas

[SilentDemise]

Was willst du denn erreichen? Und was ist für dich eine Global Collection?

[Lsteinme]

In diesem Fall brauche ich defakto das LDAP um einen Namen auf zulösen.

Ich meinte Global Catalog, sorry.

also sowas in der Richtung hier:

Binding to the Global Catalog (Windows)

[lbm1305]

Geht die Beschreibung des Zieles genauer?

Ansonsten geht das hier vielleicht:

var windowsIdentity = WindowsIdentity.GetCurrent();


var principalContext = new PrincipalContext(ContextType.Domain, pfad_zum_ldap-server, name_container);


var userPrincipal = UserPrincipal.FindByIdentity(principalContext, windowsIdentity.Name);

//var userPrincipal = UserPrincipal.FindByIdentity(principalContext, "max.mustermann");

[Lsteinme]

Ok ganz genau, brauch ich aus unserem LDAP für einen Benutzer von dem ich nur das Anmeldekuerzel weis,

Vorname, Nachname, Organisation, Telefon und Fax.

der Zugriff auf das ganze funktioniert auch, unter Windows XP mit folgendem Code:

Konstrukor des Objekts über das Zugriff aufs LDAP genommen wir:

Dim oCont As Object = GetObject("GC:")

        For Each gc As Object In oCont

          gcPath = gc.ADsPath

        Next

Zugriffsmethode:

 ''' <summary>Erweiterte Benutzer Infos aus Kuerzel</summary>

    Public Function getExtendedUserDataFromCn(ByVal Kuerzel As String) As String()

        'Try

        If Not openCon() Then

            MsgBox("Failed to connect to LDAP")

            Return Nothing

        End If


        Dim fields(6) As String


        rs = conn.Execute("<" & gcPath & ">;(Kuerzel=" & Kuerzel& ");" & _

            "AT1, AT2, AT3, AT4,AT5,AT6,AT6;subtree")


        If Not (rs.BOF Or rs.EOF) And rs.RecordCount = 1 Then

            With rs.Fields

                fields(0) = .Item(0).Value.ToString 'Nachname

                fields(1) = .Item(1).Value.ToString 'Vorname

                fields(2) = .Item(2).Value.ToString 'NT-User

                fields(3) = .Item(3).Value.ToString 'EMail-Adresse

                fields(4) = .Item(4).Value.ToString 'Organisation/Abteilung

                fields(5) = .Item(5).Value.ToString 'Telefon

                fields(6) = .Item(6).Value.ToString 'Fax

            End With

        Else

            fields = Nothing

        End If


        closeCon()


        Return fields

        'Catch e As Exception

        '    MsgBox(e.Message)

        'End Try

        Return {}

    End Function

openCon:

 

 Private Function openCon() As Boolean


      'Verbindung mit LDAP herstellen

      conn = New ADODB.Connection


      Try

         conn.Open("Provider=ADSDSOObject")

         Return True

      Catch ex As Exception

         conn.Close()

         Return False

      End Try


   End Function

So wie gesagt, unter Windows XP funktioniert das ganze ohne Probleme. Versuche ich aber das selbe Programm unter Windows 7 aufzurufen, scheitert schon das beziehen des Strings gcPath. Der Dedugger hat mir gezeigt, das das Objekt das ich mit

Dim oCont As Object = GetObject("GC:")

bekomme keine "Unterobjekte" oder was auch immer mit

 For Each gc As Object In oCont

abgerufen wird, besitzt, den der Debuggzeiger springt einfach über die schleife drüber.

Mein Verdacht hier ist, wobei ich zugegebener Maßen von Servern so ziemlich keine Ahnung habe, das irgendwie der .GetObjekt befehl vom OS des Servers falsch verarbeitet wird wenn er von einem W7 64Bit System kommt. Ist das möglich?

Nur um es nochmal zu verdeutlichen, starte ich das ganze von einer im Rechner verbauten Platte geht alles ohne Probleme, versuche ich das ganze aber vom Firmen eigenen (ich glaub fast globalen) Server, auf dem das Programm als .exe abgelegt wird, so scheitert das ganze.

PS: ich weiß leider nicht welches Betriebssystem auf dem Server drauf ist, deswegen generel gefragt, ob sowas sein. kann.

Bearbeitet 12. Juli 2013 von Lsteinme

[Lsteinme]

Als zusätzliche Seitenmerkung:

es treten noch mehr, wie ich finde komische Dinge, auf die, denke ich zumindest, vielleicht mit dem Server zutun habe:

Wenn ich ein anderes Programm vom gleichen Server starte, bekomme ich, ohne das sich das Programm überhaupt irgendwie rührt, die altbekannte Meldung Programm X funktioniert nicht mehr und muss beendet werden.

Ich hab dann raus bekommen, das es beim starten der exe des tools immer deswegen hier aussteigt:

at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)

at System.Net.Sockets.TcpListener..ctor(IPAddress localaddr, Int32 port)

at System.Runtime.Remoting.Channels.ExclusiveTcpListener..ctor(IPAddress localaddr, Int32 port)

at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel()

at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider, IAuthorizeRemotingConnection authorizeCallback)

at System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(IDictionary properties, IClientChannelSinkProvider clientSinkProvider, IServerChannelSinkProvider serverSinkProvider)

at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.RegisterChannel(Boolean SecureChannel)

at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)

at [ANWENUNGSNAME].My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81

at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)

at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext, String[] activationCustomData)

at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone()

at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

at System.Threading.ThreadHelper.ThreadStart()

Wobei dieses Problem nur bei mir auftritt oder sich zumindest noch kein anderer gemeldet hat bei dem es auch auftritt. Allerdings hab ich auch schon von leuten gehört bei denen das starten dieses Tools geklappt hat.

Diese jedoch bekommen später ein Problem, wenn die Anwendung über eine Outlook-COM verbindung Kuerzel auflösen will, um sie für Mails bereit zu stellen.

Da auch diese Anwendung die Probleme nur aufweist wenn man sie von einem Serververzeichnis aus startet, bestärkt sich halt mein Verdacht das vielleicht was mit dem Server faul ist, von der IT bekomm ich aber immer nur gesagt: da ist alles in Ordnung.

brauche also Schlagfeste Argumente^^

[lbm1305]

Schau mein letztes Posting an:

Die Klassen findest Du unter: System.DirectoryServices.AccountManagement;

zusätzlich stehen dir dann folgenden Eigenschaften zur Verfügung:

var userPrincipal = UserPrincipal.FindByIdentity(principalContext, windowsIdentity.Name);


Console.WriteLine("Vorname: {0}", userPrincipal.GivenName);

Console.WriteLine("Nachname: {0}", userPrincipal.Surname);

Console.WriteLine("E-Mail: {0}", userPrincipal.EmailAddress);

Console.WriteLine("Telefon: {0}", userPrincipal.VoiceTelephoneNumber);


// und noch mehr ;-)

Im Beispiel davor kannst Du entweder den Namen angeben oder bspw. die Windows Identity angeben.

Code läuft unter Windows 7 x64 mit .NET 4

Das Auslesen des Users ist im Gegensatz zu Deinem Beispiel nur 2 Zeilen lang.

Bearbeitet 12. Juli 2013 von lbm1305

[Lsteinme]

werd ich gleich mal testen danke, trotzdem wüsst ich gern was diesesn Rattenschwanz unter W7 auslöst

[Lsteinme]

und wenn ich da jetzt die Faxnummer au noch brauch? die hat ja Userprincipal nicht direkt als Attribut, gibts da irgend ne spezialzugriffsmethode mit der man über den Attributsnamen im LDAP auf das Attribut zugreifen kann?

[lbm1305]

How to use AD Attributes not represented in UserPrincipal, GroupPrincipal and ComputerPrincipal | Raymund Macaalay's Dev Blog