Formation MIIS, Kerberos, Active Directory et LDAP

Formation MIIS, Kerberos, Active Directory et LDAP

ILINFO vous propose formation et transfert d'expertise sur les technologies d'annuaire et de gestion d'identité.
En particulier, ILINFO vous propose des formations sur MIIS (Microsoft Identity Information Service) et ses nouvelles versions ILM (Identity Lifecycle Manager) et Microsoft Forefront Identity Manager 2010.
ILINFO propose également des formations sur Active Directory, ADAM (Active Directory Application Mode), Kerberos et LDAP.
Les formations sont adaptées à vos besoins. Elles peuvent couvrir l'administration et / ou le développement en CSHARP ou C++.

Actualité du site

Dernières nouveautés du site Formation MIIS, Kerberos, Active Directory et LDAP :

• Nettoyage des comptes inactifs de l'Active Directory
  Sans solution de provisionning et de workflow performant, le nombre de comptes utilisateurs inactifs dans l'Active Directory va vite devenir important. Développement script ADSI Sécurité ADSI : Liste Objets AD : Users, Groups, Computers, Utilisateurs, groupes, ordinateurs Il s'agit d'utilisateurs qui ont quitté la société, de comptes utilisateurs qui ne sont plus utilisés ou de machines qui ont été recyclées mais dont les objets existent toujours dans l'AD. disable accounts désactivation de comptes Nettoyage comptes inactifs Pour déterminer si un compte est toujours utilisé ou non, il existe deux moyens simples qui peuvent d'ailleurs être complémentaires et recupés ensembles. Il s'agit par exemple de s'appuyer sur l'attribut LastLogonTimeStamp (à partir de Windows 2003) qui stocke la date de dernier logon du compte. Cet attribut est répliqué sur tous les dc du domaine. La seconde données intéressante est la date de dernier changement de mot de passe. Une machine change son mot de passe tous les 30 jours. Si un ordinateur n'a pas changé son mot de passe depuis par exemple 60 ou 90 jours, il y a de fortes chances que cette machine n'existe plus sur le domaine. Voici un ensemble de scriptsqui permet de générer la liste des utilisateurs et ordinateurs inactifs (stale accounts dans le jargon anglosaxon) et de réaliser le nettoyage (le script recensé désactive le compte et le déplace dans une OU de quarantaine. La date d'action et le chemin source de l'objets sont stockés dans des attributs inutilisés pour un éventuel retour arrière). Développement script ADSI Stale Accounts Liste les objets Users, groups et computers de l'AD : Développement script ADSI Comptes inactifs, Comptes désactivés Liste les comptes inactifs de l'AD Liste les comptes désactivés de l'AD Développement script ADSI nettoyage AD LastLogonTimeStamp, Last Password Change Désactive les comptes inactifs de l'AD
• Page de test Kerberos et de délégation ASPX
  Utile, cette page permet de vérifier le protocole d''authentification utilisé lors d'un accès à un serveur web IIS. Il permet de vérifer par exemple si l'accès se fait en Kerberos. Copier simplement le contenu suivant dans un fichier et nommez le identity.aspx. Créez également un fichier web.config, et placez les 2 fichiers dans le même répertoire. Le lien suivant permet de télécharger cet exemple ainsi qu'un exemple additionnel de test de délégation Kerberos. La page frontal.aspx essaie de lire un fichier sur un serveur tierce en utilisant l'identité du client. Pour le faire fonctionner, créer un fichier de test sur un serveur distant, partagez le et donnez les permissions uniquement à l'utilisateur. S'il arrive à le lire à travers la page frontal.aspx, c'est que la délégation Kerberos fonctionne. Modifiez le paramètre identity impersonate pour voir les différences de comportement. Download  -------------------------------------------------    web.config --------------------------------- <configuration>   <system.web>     <authentication mode="Windows"/>     <authorization>         <deny users="?" /> <!-- Deny anonymous users -->     </authorization>     <identity impersonate="false" />     <compilation debug="true"/>   </system.web> </configuration> ----------------------------------------------        identity.aspx        ----------------------- <%@ Page language="VB" %> <%@ Import namespace = "System.web" %> <script language="VB" runat="server">    Dim AuthLength    Dim AuthOther   public sub page_Load( Obj as Object, e as Eventargs)      Authuser.text= HttpContext.Current.User.Identity.Name().Tostring     ThreadId.text= System.Security.Principal.WindowsIdentity.Getcurrent().name().Tostring()      ' Get the authentication method being used    AuthMethod.text = Request.ServerVariables("AUTH_TYPE")    AuthLength = Request.ServerVariables("HTTP_Authorization")   ' If some other authentication method (other than Negotiate) gets used, call it "Other"    If LTrim(RTrim(AuthMethod.text)) <> "Negotiate" Then AuthOtherMethod    ' If Negotiate gets used, go straight to the subroutine to handle it    If LTrim(RTrim(AuthMethod.text)) = "Negotiate" Then AuthNegotiateMethod   End sub Sub AuthOtherMethod()        ' Since anonymous authentication will be blank, let's be sure we realize it's enabled to        If LTrim(RTrim(AuthMethod.text)) = "" Then AuthMethod.text = "Anonymous" End Sub Sub AuthNegotiateMethod()        ' Typically, NTLM will yield a 150 - 300 byte header, while Kerberos is more like 5000 bytes        If LEN(AuthLength) > 1000 Then AuthType.text = "Kerberos"        If LEN(AuthLength) < 1000 Then AuthType.text = "NTLM" End Sub </script> <html> <body> Authentication Method : <asp:label id=AuthMethod runat=server /><br> Protocole : <asp:label id=AuthType  runat=server /><br> Authenticated user: <asp:label id=Authuser runat=server /><br> Thread identity   : <asp:label id=ThreadId runat=server /> </body> </html>    
• PRA : Restauration d'une forêt Active Directory
  Blog PRA Active Directory Forest Recovery Lors d'un désastre Active Directory nécessitant une reconstruction complète de la forêt, la première chose à réaliser est de restaurer le service au plus vite, en l'occurence le service d'authentification. Blog PRA Active Directory Forest Recovery Le minimum à réaliser consiste à réinstaller un DNS sur lequel va s'appuyer l'AD, un controleur de domaine du domaine racine, un controleur de domaine de chaque domaine enfant ainsi qu'un global catalogue. A ce stade, le service minimum est restauré, les étapes suivantes consistent reconstruire un DC dans chaque site puis remonter tous les DC, et remettre en place les rôles FSMO. Pour que le service d'authentification soit complètement opérationnel, celà nécessite également dans la majorité des cas qu'un catalogue global soit accessible (cas d'une forêt en mode natif nécessitant un GC pour résoudre l'appartenance aux groupe universels). Forest Recovery Cependant, savez-vous que pour promoter un GC, le rôle FSMO Schema Master doit être accessible? Celà implique donc que le DC possédant ce rôle devrait être restauré avant toute tentative de restauration de GC. Si la sauvegarde de ce DC n'est pas accessible, il est possible de forcer ce rôle sur un DDC (Seizure). Cependant la seizure de ce rôle nécessite d'être dans le groupe Schema Owner. PRA Active Directory Chez un de mes clients, le scénario suivant est survenu: ils avaient retiré le compte Administrator du groupe Schema Owner. Après restauration du premier DC, première surprise, l'administrateur ne peut seizer ce rôle, ni modifier le contenu de ce groupe, ni même se loguer avec un compte possédant les droits puisqu'aucun GC n'est disponible. Comment faire alors pour installer le premier GC de la forêt? Solution 1. Se placer dans le contexte LocalSystem du DC Sur le serveur, ou dans une console système (mstsc /console), dans une invite de commande, lancez la commande at /interactive hh:mm cmd.exe hh:mm représentant l'heure actuelle+ 2 minutes. 2. Lancez adsiedit.msc dans le contexte système. Lorsque l'invite de commande apparait dans le contexte système, tapez adsieedit.msc puis appuyez sur Entrée. Chargez la partition schema puis modifiez manuellement le DC possédant le rôle Schema Master (Attribut FSMORoleOwner de CN=SCHEMA,CN=Configuration,DC=...) Forest Recovery   Blog PRA Active Directory La prise en compte est dynamique. A ce stade, vous avez seizé le rôle Schema Master sur le DC que vous avez restauré sans pour autant appartenir au groupe qui donne cette autorisation.  Maintenant que le rôle est assigné, vous pouvez promoter un GC. Promotion du GC Bien que tous les domaines ne soient pas encore restaurés, il est possible de  promoter un GC "vide". Normalement il ne s'annoncera comme GC seulement lorsqu'il aura réussi à répliquer une fois la partition de chaque domaine. Il est cependant possible de changer ces contraintes en éditant la clé de registre HKEY_LOCAL_MACHINE \ SYSTEM \ Current Control Set \ Services \ NTDS \ Parameters \ Global Catalog Partition Occupancy. En la positionnant à zéro, vous indiquez au système qu'il peut s'annoncer en tant que GC dès que 0 partitions sont disponibles. Promotez maintenant votre GC, il s'annonce immédiatement en tant que GC bien qu'il ne possède que la partition de votre domaine. Vérification: Lancez LDP, cliquez sur Connect et laissez les entrées à vide, cliquez ensuite sur Bind et laissez les entrées à vide. Vous êtes alors connecté au DC qui vous affiche alors ses  capacités. Regardez la valeur de 'attribut :                 1> isGlobalCatalogReady: True;       Votre domaine racine est maintenant opérationnel et poss_de un premier GC. Ses utilisateurs peuvent désormais s'authentifier. Vous pouvez maitenant restaurer un DC de chaque domaine pour restaurer les domaines un par un ou utiliser vos outils ou scripts de Forest Recovery pour dérouler la suite de votre PRA (Plan de reprise d'acitvité).
• Configuration IIS pour la délégation et l'authentification Kerberos
  Configurer l'authentification intégrée Windows dans IIS n'est pas en soi très compliqué. Les scénarios se compliquent cependant lorsqu'il s'agit de mettre en place Kerberos sur des serveurs mutualisés ou sur des fermes de serveurs Web. Configuration IIS pour Délégation Kerberos Délégation Kerberos Configuration IIS  Ce billet décrit pas à pas la configuration à mettre en place. 1. Configuration de l'identité de l'application Pool. L’authentification Kerberos ne fonctionnera pas dans le cas d’une ferme de serveurs IIS dont les application pool s’exécuteraient sous Network Service ou Local Sytem/Service  car le SPN nécessaire à l'authentification Kerberos ne pourrait pas être enregistré sur les différents compte d'ordinateur de la ferme. Configuration IIS pour Délégation Kerberos Pour permettre l'authentification Kerberos sur une ferme Web ( Ferme NLB, boitier F5 etc.), l'application Pool d'IIS doit s'exécuter sous l'identité du même compte utilisateur du domaine sur chaque serveur. Le SPN correspondant à l'URL de connexion sera enregistré sur ce compte. Dans cette configuration, le navigateur peut demander un ticket Kerberos pour la chaine SPN spécifiée et présenter le ticket Kerberos à chaque noeud de la ferme web puisque chauqe noeud tourne sous le même compte d'utilisateur du domaine. Délégation Kerberos Dans l'Active Directory, créez simplement un compte utilisateur, dit compte de service, et positionnez les flags « User cannot Change Password » et « Password never expires ». 2. Configuration d'IIS Créez ensuite dans IIS un nouveau pool d'application et définissez comme identité le compte que vous venez de créer.  Créez ensuite le site web, puis configurez le pour s’exécuter dans le pool d’application précédemment configuré. Cas particulier: Environnement mutualisé   Dans le cas où le serveur héberge plusieurs sites IIS, il faut pouvoir séparer les instances de IIS. Celà peut être réalisé de 2 manières: -    soit en les différençiant grâce à un numéro de port différent. -    soit en les différençiant par le host header. La première solution presente le désavantage d’avoir à manipuler des numéros de port nécessaires pendant la construction du SPN. Les navigateurs se comportant différemment, certains risquent de ne pas passer le numéro de port pendant la construction du SPN, au final le SPN demandé ne sera pas trouvé ou un ticket Kerberos pour le mauvais compte sera retourné par l'AD. De plus, il risque sur la route d'y avoir des réécritures de port: (ex à travers un boitier F5) et le port passé dans la construction du SPN par le client ne sera pas nécessairement celui enregistré dans le SPN dans l'AD. Afin d’avoir une meilleure maitrise de la solution  et s’assurer d’une configuration qui fonctionne dans tous les cas, la  seconde solution  est à privilégier lorsque c’est posible. Elle nécessite la configuration du Host Header dans le site IIS. Dans le scénario le plus simple, ce host header doit correspondre à une entrée de type A (host) dans le DNS (et pas une entrée de type CNAME (Alias) dans le DNS) et être enregistré au niveau des SPN sur le compte de service de l’application pool.  Ainsi, lorsque le navigateur Internet Explorer, demande l’URL http://portaldns, il demande un ticket kerberos pour le SPN http/portaldns enregistré sur le compte de service domAD\svcdnsadmin. Il le presente alors au serveur IIS qui grâce au host header portaldns redirige la requête vers la bonne instance. Si un alias est enregistré au niveau host header, le spn associé à l’entrée de type host correspondant à l’alias DNS doit également être enregistré en tant que SPN. Vous pouvez placer plusieurs host headers sur un même instance IIS (ie plusieurs URL d’accès). Importance du Host vs ALIAS DNS   Les navigateurs se comportent tous différemment. Ainsi, lors de la construction du SPN, Internet Explorer fait une résolution DNS du nom de serveur spécifié dans l'URL et construit par défaut un SPN de type host/fqdn ou fqdn est le nom de host (type A) présent dans le DNS, même si dans l'URL un alias DNS (type CNAME) a été spécifié. en d'autre terme, si vous demandez http://alias, le spn construit sera http/host. Le mécanisme peut être inversé par le biais d'un htofix. Je ne recommande personnellement pas la modification de ce comportement. Il est en effet élégant d'avoir à n'enregistrer qu'un seul SPN dans l'AD (celui du host) et de pouvoir avoir une multitude d'aliases. Firefox par contre utilise le nom passé dans l'URL sans transformer l'alias en host. Dans le scénario de host header, si IIS est accédé par une url contenant un alias, il faudra enregistrer en SPN le host et l'alias pour que ça fonctionne depuis n'importe quel navigateur. 3. Configuration supplémentaire  A ce stade,ça ne fonctionne pas encore. Il faut donner les bonnes permissions au compte de service sur le serveur. Le compte de service nouvellement crée a besoin de permissions sur la metabase IIS et de permissions sur le répertoire temporaire %Windir%\Microsoft.NET\Framework\version\Temporary ASP.NET La commande aspnet_regiis –ga réalise ces 2 opérations. Lancez: aspnet_regiis -ga Domain\AccountName Ensuite, rajoutez le compte d’identité du pool d’application IIS dans le groupe local IIS_WPG. Rajoutez maintenant les SPN requis sur le compte de service du pool d'application à l'aide de la commande setspn. Ex: setspn -a http/portaldns domAD\svcportaladmin et setspn -a http/alias  domAD\svcportaladmin enregistrent les SPN pour le host et l'alias sur le compte de service. Celà permet de faire fonctionner kerberos dans la majorité des cas. Plusieurs aliases peuvent être ajoutés.  4. Délégation Kerberos Pour terminer, la délégation Kerberos doit être mise en place. Le compte de service doit être approuvé pour la délégation (Trusted for Delegation) dans l'Active Directory et pour des raisons de sécurité, les contraintes de délégation doivent être mises en place, c'est à dire lister uniquement les TGS Kerberos (représentés par les SPN)  que le compte de service est autorisé à demander.    Le compte de service nouvellement crée a besoin de permissions sur la metabase IIS et de permissions sur le répertoire temporaire %Windir%\Microsoft.NET\Framework\version\Temporary ASP.NET La commande aspnet_regiis –ga réalise ces 2 opérations. Lancez: aspnet_regiis -ga Domain\AccountName   Dans le cas d’une application ASP.NET, le fichier web.config doit être configuré de la façon suivante : http://support.microsoft.com/kb/810572 Bien évidemment, pour que la délégation Keberos fonctionne, cela nécessite au préalable une authentification du poste client et donc désactivation de l’authentification anonyme et l’activation de l’authentification intégrée. Au niveau Internet Explorer, l’authentification intégrée doit être activée, et l’URL résolue en tant que site Intranet (c’est souvent le proxy.pac qui détermine si l’url est locale ou non).
• DDNS par un serveur DHCP
  Voici un billet dédié à la mise en place de dynamic update DNS réalisé par les serveurs DHCP en lieu et place du client, ceci afin de restreindre les permissions d'écriture sur les zones DNS. 1. Rappel du paramétrage du client Pour que le client réalise son enregistrement DNS dynamique, il faut que la case "Enregistrer les adresses de cette connexion dans le système DNS" soit cochée. Le client enregistre alors ses entrées dans le domaine spécifié par le suffixe DNS principal de cette machine. Lorsque la case “Utiliser le suffixe DNS de cette connexion pour l’enregistrement DNS” est cochée, la station s’enregistre également dans la zone mentionnée dans le champs “Suffixe DNS pour cette connexion”, ce qui permet de réaliser des doubles enregistrements. Pour que la station de travail ou le serveur ne tente pas un enregistrement dynamique, il faut que la case “Enregistrer les adresses de cette connexion dans le système DNS” soit décochée.Pour les postes configurés en DHCP, il est alors possible  de configurer le DHCP pour qu’il réalise l’enregistrement DNS à la place du client. 2. Configuration du DHCP L'activation du DDNS par le serveur DHCP peut être configuré au niveau du scope ou au niveau du serveur DHCP. Il faut activer le DDNS et demander l’enregistrement même pour les hosts qui n’en font pas la demande. Par exemple, pour activer le DDNS pour tous les scopes hébergés par le serveur DHCP, configurez le DDNS au niveau du serveur DHCP. Configurez les options suivantes:   L’enregistrement aura lieu dans le domaine mentionné par l’option 15 du scope DHCP.  3. Déploiement des paramètres par GPO La désactivation de "Enregistrer les adresses de cette connexion dans le système DNS" peut être réalisée par GPO, il faut désactiver Dynamic Update et Register PTR Records. 4. Permissions sur les zones DNS Par défaut, à la création d'une zone DNS intégrée AD, le groupe Tout le mondea les permissions de rajouter des entrées et modifier et supprimer ses propres entrées, ceci afin que le dynamic Update puisse ajouter des entrées. Pour restreindre les permissions, il faut donc retirer à tout le monde les permissions de créer des entrées. Il faut ensuite autoriser les serveurs DHCP à ajouter des entrées et modifier ses enregistrements. C'est le cas par défaut si les DHCP sont installés sur des controleurs de domaine. Si ce n'est pas le cas, un groupe contenant les serveurs DHCP peut être autorisé à créer/modifier/supprimer des entrées DNS. Dans les paramètres du serveur DHCP, iles est également possible de spécifier le compte utilisateur qui sera utilisé pour réaliser les enregistrements dynamiques. Ce compte devra avoir les permissions nécessaires pour gérer les enregistrements DNS. Note: Lors du DDNS réalisé par DHCP, celui-ci devra avoir le droit d'écraser (mettre à jour) des enregistrements existant, donc simplement créer des enregistrements et modifier ses propres enregistrements (par le biais de SELF) est insuffisant. 5. Scavenging Il est interessant en même temps que la mise en place du DDNS de mettre en place le nettoyage automatique des enregistrements crées par DDNS (Scavenging). Le scavenging doit être activé au niveau du serveur DNS (sur 1 seul , car les suppressions se répliquent  aux autres), et également sur chaque zone gérée. Les valeurs par défaut de 7 jours peuvent être conservées. Lorsque le scanvenging est activé, seuls les enregistrements crées par dynamic update sont touchés, un enregistrement statique ne sera jamais supprimé. Pour gérer celà, le scavenging s'appuie sur un timestamp lié à l'enregistrement, et ce timestamp n'est crée que lors de la création par DDNS. Si vous avez des doutes sur les enregistrements qui risquent d'être supprimés lors de l'activation du scavenging, vous pouvez lister les entrées d'une zone à l'aide de dnscmd.exe et lister celle qui possèdent un entrée [aging]. ex: dnscmd dnsserver /enumrecords dnszone @ > dnsdump.txt puis findstr /i "aging" dnsdump.txt > aging.txt
• SetupDiOpenDeviceInterface returns ERROR_INVALID_USER_BUFFER in C#
  Lors du développement de l'outil USBLIST disponible en téléchargement sur mon site, je me suis arraché les cheveux pendant un bon moment sur l'appel de SetupDiOpenDeviceInterface en CSHARP  (C#). En effet cette API n'est pas exposée dans ce langage et il faut appeler la fonction native de setupapi.dll par pinvoke. Cependant tous mes appels se sont soldés par une erreur ERROR_INVALID_USER_BUFFER sans comprendre pourquoi. Les recheches sur Internet et les questions sur les forums se sont révélées infructueuses et aucun exemple de code source fonctionnel n'était disponible pour s'en inspirer. Le seul moyen de trouver la cause du problème a été de développer un exemple en C++ et de comparer son exécution en assembleur avec le programme en C# pour comprendre les différences. Voici les extraits clés de la session de debugging: SP_DEVICE_INTERFACE_DATA DeviceInterfaceData; DeviceInterfaceData.cbSize = sizeof(DeviceInterfaceData);[...] if (SetupDiOpenDeviceInterface(  DeviceInfoSet,  lpdbv2->dbcc_name,  0,  &DeviceInterfaceData  )== 0) Au breakpoint suivant, l'instruction compare la taille de DeviceInterfaceData.cbSize. Le registre ecx contient la valeur de la donnée. eax=76d9c680 ebx=76d9c65c ecx=0012fa14 edx=00000000 esi=00000000 edi=001e2c28 eip=76cbca46 esp=0012f460 ebp=0012f464 iopl=0         nv up ei pl zr na pe nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246 SETUPAPI!DeviceInterfaceDataFromNode+0x3a: 76cbca46 83391c          cmp     dword ptr [ecx],1Ch  ds:0023:0012fa14=0000001c 0:000> dd ecx 0012fa14  0000001c cccccccc cccccccc cccccccc 0012fa24  cccccccc cccccccc cccccccc cccccccc 0012fa34  cccccccc 001e2c28 cccccccc cccccccc 0012fa44  001e22f8 cccccccc cccccccc cccccccc 0012fa54  cccccccc cccccccc 001e22f8 cccccccc 0012fa64  cccccccc cccccccc cccccccc cccccccc 0012fa74  cccccccc cccccccc cccccccc cccccccc 0012fa84  cccccccc cccccccc cccccccc cccccccc Le même code en # (apparemment)! SP_DEVINFO_DATA DeviceInfoData = new SP_DEVINFO_DATA(); // Note it should be SP_DEVICE_INTERFACE_DATA but the structures are identical // DeviceInfoData.cbSize = Marshal.SizeOf(DeviceInfoData); DeviceInfoData.cbSize = 28; if (!SetupDiOpenDeviceInterfaceA(     hDev,     // dvi.dbcc_name,     @"\\?\USB#VID_07AB&PID_FCCA#FW520_200000000000B703#{a5dcbf10-6530-11d2-901f-00c04fb951ed}",     0,     ref DeviceInfoData)) Le breakpoint à la même instruction: 0:000> t Breakpoint 1 hit eax=76d9c680 ebx=76d9c65c ecx=002aeaac edx=00000000 esi=00000000 edi=005f70c0 eip=76cbca46 esp=002ae820 ebp=002ae824 iopl=0         nv up ei pl zr na pe nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246 setupapi!DeviceInterfaceDataFromNode+0x3a: 76cbca46 83391c          cmp     dword ptr [ecx],1Ch  ds:0023:002aeaac=00612a18 0:000> dd 002aeaac 002aeaac  00612a18 00196fd8 5c3f5c5c 23425355 002aeabc  5f444956 42413730 44495026 4343465f 002aeacc  57462341 5f303235 30303032 30303030 002aeadc  30303030 33303742 35617b23 66626364 002aeaec  362d3031 2d303335 32643131 3130392d 002aeafc  30302d66 66343063 31353962 007d6465 002aeb0c  00196c00 002aeb24 79e7b080 00000006 002aeb1c  00196ca8 00000006 002aeb30 79e7b06b 0:000> dd poi(ecx) 00612a18  0000001c 00000000 00000000 00000000 00612a28  00000000 00000000 00000000 abababab 00612a38  abababab feeefeee 00000000 00000000 00612a48  63574a97 00000e3e 00612ae0 00581fc0 Forcément, ça plante  car ecx ne contient pas 0000001C mais l'adresse mémoire où est stocké 1C. La fonction sort donc en erreur et retourne 0x6f8 ERROR_INVALID_USER_BUFFER Pour résumer, En C++ , ecx contient la longueur de la structure. En c#, par contre, ecx contient l'adresse mémoire de la longueur de la structure. Pour résoudre le problème, il a suffit de remplacer la classe SP_DEVINFO_DATA par une structure qui n'a donc pas besoin d'être instanciée. Le code source est disponible ici: http://www.ilinfo.fr/docs/DeviceInformation.cs Post Original : http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/2eca9b5d-fd96-4181-943f-3157a09020f0        
• Problème restauration des comptes associés aux keytab
  Contexte: Un administrateur a mis en place une solution de SSO pour que des utilisateurs d'un domaine Active Directory puissent s'authentifer en Kerberos auprès d'applications JAVA ou aurpès d'applications hébergées sur des machines Unix ou Linux. Dans ce contexte, des comptes SSO ont été crées dans l'Active Directory. Il s'agit de comptes de service pour lesquels un keytab a été généré à l'aide de la commande Ktpass.exe (ktpass -princ 'value' -mappuser domain\svcaccount etc.) Lors de l'éxécution de la commande, le mot de passe du compte de service est modifié et la clé de chiffrement contenue dans le keytab est dérivée du mot de passe. Un numéro de version du mot de passe appelé kvno est également stocké dans le keytab. Il doit correspondre au numéro de version contenu dans les tickets générés par les KDC. Le KDC récupère le numéro de version depuis l'attribut msDS-KeyVersionNumber. Cet attribut msDS-KeyVersionNumber est un attribut construit (constructed attribute) dont la valeur est égale à une metadonnée de l'attribut UnicodePwd.   Problème: Lors d'une restauration autoritaire (authoritative restore), la métadonnée de l'attribut UnicodePwd est incrémentée de 100 000. Celà a une double conséquence: 1.  le msDS-KeyVersionNumber (= kvno) est également incrémenté de 100 000 et ne correspond donc plus au numéro de version stocké dans le keytab. En d'autres termes, celà invalide le keytab existant qu'il faut alors regénérer. 2. Le kvno est originellement codé sur 8 bit et accepte des valeus de 0 à 255. Les valeurs supérieures sont alors mal perçues selon les implémentations kerberos. L'implémentation MIT par exemple accepte des kvno > 255 alors que l'implémentation de Vintela (Quest) ne les accepte pas. Dans un cas de PRA (plan de reprise d'activité, DRP en anglais), où il faut procéder à une restauration autoritaire d'annuaire, il faut alors regénérer tous les keytab des comptes SSO Kerberos Unix et les réinstaller dans chaque application. Si la stack kerberos n'accepte pas les kvno > 255, il faut alors supprimer tous les comptes SSO et les recréer.   Contournements: Vintella accepte des keytab avec un kvno à -1 et dans ce cas ignore si les numéros de version ne correspondent pas (ce n'est pas applicable pour l'implémentation MIT). Il est donc possible d'éditer les fichiers keytab existants avec un éditeur héxadécimal et de forcer la valeur kvno à FF. Il est également possible de générer un keytab avec la valeur kvno à -1, pour cela utiliser l'option de ktpass /kvno 255.  Finalement, il est possible de forcer l'active directory à revenir à la mode Windows 2000 c'est à dire ne jamais incrémenter le  msDS-KeyVersionNumber et lui forcer la valeur à 1 systématiquement. Pour celà, il faut modifier au niveau de la forêt dans la partition configuration l'attribut dsheuristics. voir http://support.microsoft.com/kb/870987/en-us   Demande de fix : Une demande de fix (CDCR = Critical Design Change Request) a été formulée auprès de Microsoft. Ce billet sera mis à jour lorsqu'un statut final sera apporté par Microsoft.
• Gpresult Access Denied
  Problème: Après une migration de domaine réalisée à l'aide d'ADMT les utilisateurs reçoivent un ACCESS DENIED lors de l'utilisation de Gpresult.exe. Problème cosmétique, la commande se déroule pourtant correctement. En lançant à distance l'outil rsop.msc, 2 SID sont proposés pour le même utilisateur. Explication: Le problème survient du fait que sous le namespace root\RSOP\Users, l'ensemble des SID des utilisateurs qui se sont logués sur la station et qui ont par conséquent eu des GPO appliquées sont stockés sous ce namespace. Lors du gpresult, celui ci fait une requête WMI et tente de récupérer les informations de l'utilisateur. Il subsiste le SID de l'utilisateur avant migration et gpresult s'enmêle alors les pinceaux, même si à priori les permissions semblent correctement positionnées. Résolution: Pour remédier à ce problème, il suffit de supprimer toutes les entrées "SID" sous le namespace root\RSOP\Users à l'aide du script ci dessous. Ces entrées seront dynamiquement recréées lorsque les GPO se réappliqueront à un utilisateur logué, elles peuvent donc être supprimer sans impact. --------------------   RepairWMI.vbs     --------------------- strComputer = "." Call EnumNameSpaces("root\RSOP\user")   Sub EnumNameSpaces(strNameSpace)     'WScript.Echo strNameSpace     Set objWMIService=GetObject _         ("winmgmts:{impersonationLevel=impersonate}\\" & _             strComputer & "\" & strNameSpace)     Set colNameSpaces = objWMIService.InstancesOf("__NAMESPACE")     For Each objNameSpace In colNameSpaces         if ( Instr(objNameSpace.Name,"S_1_5_21")) Then                 wscript.echo "Suppression de " & objNameSpace.Name                 strPath = _                 "winmgmts:\root\RSOP\user:__Namespace.Name='" & objNameSpace.Name & "'"                 GetObject(strPath).Delete_         Else                 Call EnumNameSpaces(strNameSpace & "\" & objNameSpace.Name)         End If     Next End Sub --------------------------------------------------------------

Retrouvez le flux de syndication associé en cliquant sur cette icône :

ILINFO Freelance Indépendant Architecture, Conseil, Audit ... : Le site de ILINFO, société créee par un indépendant,Freelance,Expert en technologies Microsoft,Active Directory, PKI , MIIS et sécurité,Vista
Références clients de ILINFO : Audit, Conseil en architecture ... : Les références clients de ILINFO. Architecture AD, DRP et BCP, SCOM 2007, Formations ADAM, MSMQ, CLUSTER ... stockés dans des conteneurs ADAM. Formation MSMQ ...