Bonjour,
Une nouvelle version du moteur de synchronisation (DirSync) est disponible.
Il corrige des problèmes de fuite mémoire, et des erreurs de staging lors de l’opération “confirming import”.
Vous pouvez l’installer et il est téléchargeable à partir de ce lien.
http://social.technet.microsoft.com/wiki/contents/articles/18429.windows-azure-active-directory-sync-tool-version-release-history.aspx
Huu-Duc LÊ
Equipe Domaine et Sécurité
Microsoft ADFS 2.0 Configuration
Création du Trust entre ADFS 2.0 et 4TRESS :
Procédure 1: Export des métadonnées de l’IDP 4TRESS
Note :
Les métadonnées de l’IDP (4TRESS) ne sont pas stockées dans la base de données de l'Appliance, mais est générée lors d’une demande d’exportation via la console de gestion.Cette demande se base sur les données suivantes :
• 4TRESS IDP hostname • 4TRESS IDP port number—(optionnel)• 4TRESS Security Domain— Le nom de domaine fait partie de l'URI définie dans les métadonnées.• Indicateur signalant si l’IDP 4TRESS accepte seulement les demandes signées — il s'agit d'un attribut facultatif qui indique que les messages de type <samlp:AuthnRequest> reçus par cet IDP sont à signer. Si ceci est omis, la valeur est à faux.• Les références des certificats de l’IDP 4TRESS (signing & encryption) stockées dans le keystore HSM.
1. Connectez-vous avec un compte administrateur de la console de management 4TRESS et saisir les credentials puis cliquer sur Submit :
2. Cliquer sur l’onglet Configuration
3. Dans le menu SAML, sélectionner 4TRESS Identity Provider.
4. Cliquer sur Export Metadata
5. Cliquer sur Open , puis save 4TRESS_IDP_METADATA.xml à l’emplacement de votre choix
================================================
Procédure 2: Création du trust
1. Lancer la console ADFS
2. Sous AD FS 2.0\Trust Relationships,ajouter un nouveau Claims Provider Trust
3. Cliquer sur Start
4. sur le page Select Data Source , cliquer sur Import data about the claims provider from a file. Dans Federation metadata file location, choisir le fichier .xml exporter au point 1, puis Next
5. Cliquer sur ok
6. Dans Specify Display Name saisir un Display name (4TRESS par exemple), sous Notes saisir une description, puis Next
7. Sur la page Ready to Add Trust, cliquer sur Next
8. Décocher la case et cliquer sur Close
Important:
If trusted certificate stores have been modified previously on this computer, verify that the SSL certificate that is used to secure the federation metadata retrieval is trusted by the service account that is assigned to this Federation Service. If the service account does not trust the SSL certificate of this claims provider, monitoring of the trust will fail. To prevent this failure, make sure that the issuer of the claims provider’s SSL certificate is in the Local Computer Trusted Root Certification Authorities certificate store on each federation server in the farm.
Procédure 3: Création de règles de transformation de claims entrants
1. Sélectionner le partenaire (4TRESS) , puis cliquer sur Edit Claim Rules
2. Cliquer sur Add rule
3. sélectionner Send Claims Using a Custom Rule ,puis Next
4. Saisir un display name et renseigner le champ comme vous le désirez, comme par exemple :
5. Cliquer sur Finish
6. Cliquer sur OK
Procédure 4: Claims Provider Trust Properties - Advanced Tab
1. Sélectionner le partenaire,puis Edit Claim Rules
2. Choisir l’option SHA-1
Procédure 5: Configuration du Relying Party Trust
1. Sous AD FS 2.0\Trust Relationships, faire un clic-droit sur Relying Party Trusts, et ajouter votre application ( ici il s’agit du sample claimapp)
2. Ajouter une issuance transform rule en cliquant sur Add rule
3. Saisir un display name, et ajouter la syntaxe suivante :
Procédure 6: Modification des métadonnées ADFS avant importation sur l’applicance
L’IDP 4TRESS retourne uniquement les valeurs d'attribut configuré dans l'assertion, si la demande d'authentification SAML d’ADFS contient une référence à cet index.
C'est pourquoi il est nécessaire d'ajouter cet attribut comme exiger (isDefault = « true ») dans les métadonnées d'ADFS.
Un exemple avec l'attribut « mail » et « prénom » :
<AttributeConsumingService index="0" isDefault="true">
<ServiceName xml:lang="en">Sample Service</ServiceName>
<ServiceDescription xml:lang="en">An example service that requires a human-readable identifier and optional name and e-mail address.</ServiceDescription>
<RequestedAttribute FriendlyName="mail" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" />
<RequestedAttribute FriendlyName="FirstName" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" />
</AttributeConsumingService>
ActivIdentity 4TRESS AAA Configuration
La suite va décrire comment configurer l'Appliance 4TRESS:
Important: You will use the ActivIdentity 4TRESS Management Console and the ActivIdentity 4TRESS Configurer to perform these procedures. This chapter only provides a summary of steps. For complete details, please have the following technical documents on hand for easy reference:
· ActivIdentity 4TRESS Authentication Appliance Identity Provider Solution Guide
· ActivIdentity 4TRESS Authentication Appliance Administrator Guide: Management Console
· ActivIdentity 4TRESS Authentication Appliance Administrator Guide: Configurer Portal
Procédure 1: Création du SAML Channel
1. Lancer la console ActivIdentity 4TRESS Management, identifiez-vous et cliquer sur Submit
2. Aller à la page Configuration/policies/Channels
4. Cliquer sur Add
4. Sous Policies, cliquer sur Channels, puis sur Add
5. Saisir un Name et Description, puis sélectionner SAML Service Provider
Procédure 2: Import des métadonnées ADFS
1. Aller à la page ADFS Microsoft SAML Details
2. Décocher Enable OneTimeUse condition
3. Cliquer sur File import , et renseigner le fichier de métadonnées ADFS
3. Cliquer sur Add
4. Sélectionner assertion attribute et lier cela à une valeur statique, un attribut User ou un attribut prédéfini puis cliquer sur OK
5. Afficher la liste des valeurs retournées dans l’assertion SAML
Procédure 3: Autoriser l SAML Channel (Authentication Policies)
1. Connectez-vous au 4TRESS AS Configurer, identifiez-vous et cliquer sur Log in
2. Cliquer sur l’onglet Authentication Policies
3. Sélectionner AT_CUSTOTP , puis Edit
4. Sélectionner Microsoft ADFS SAML et cliquer sur Update
5. sur la page Authentication Policies, sélectionner AT_CUSTPW , puis Edit
6. Répéter les étapes 3 et 4
7. Retourner dans la console de Management, puis éditer le précédent channel enregistré, afin de voir les règles d'authentification autorisés dans la section Allowed authentication Policies
Procédure 4: Configuration de l’IDP
1. Connectez-vous à la console 4TRESS Management
2. Sous Policies, développer SAML, puis cliquer sur 4TRESS Identity Provider
3. Décocher Require signed authenticate requests
4. Ajouter les authentication policies et le template ID
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedPassword
Procédure 5: ajout d’une nouvelle Authentication Policies Mapping
1. Cliquer sur Add afin de créer une nouvelle authentication policies mapping
2. Choisir le type de SAML Authentication
3. Sélectionner 4TRESS Authentication Policy
4. Sélectionner le GUI Template
5. Cliquer sur Next
6. Pour valider, cliquer sur Ok
l’authentication policies mapping est créée.
7. Cliquer sur Save
SAML Channel Authentication
Pré-requis pour activer le Web Soft Token
Le poste client doit être inscrit :
1. Dans le Main menu, Service ,sélectionner Activate Soft Token
2. Dans le menu Soft Token Type, sélectionner Web Soft Token,puis Submit.
3. Identifiez-vous puis Login
4. Cliquer sur Activate. Si le token a été configuré avec un PIN, vous serez prompté afin de saisir ce code PIN.
FIGURE 1: Exemple de login couplé au token :
The user opens a browser and enters the URL the administrator has defined in Web application. The user is redirected to the 4TRESS AS authentication portal, and then authenticates as a 4TRESS user. When authenticated, the user is redirected to the web applications pages.
L'utilisateur ouvre un navigateur et entre l'URL définie dans l'application Web. L'utilisateur est redirigé vers 4TRESS comme portail d'authentification et authentifie cet utilisateur 4TRESS.Lorsque il sera authentifié, l'utilisateur sera redirigé vers les pages de l’application web.
Joseph Besançon Domain & Security Team
S'applique à Windows 2008 R2 Server, Windows 2012 Server, Windows 2012 R2 Server hébergeant une ou plusieurs zones intégrées Active Directory.
Parmi les incidents DNS/AD sur lesquels j'ai pu intervenir, la suppression inexpliquée d'enregistrements DNS est parmi l’un des plus redondants, entre autres parce que les équipes se sentent parfois désarmées devant le nombre de causes possibles à ce comportement :
Si les causes peuvent parfois être évidentes, il faudra dans les autres cas investiguer pour identifier la source du problème en utilisant par exemple des captures réseau ou - dans le cas où les suppressions concernent une zone intégrée à l'Active Directory n'autorisant que les mises à jour sécurisées - l'audit de sécurité.
En effet, les zones intégrées à l'Active Directory forçant la mise à jour sécurisée présentent trois avantages par rapport à ce cas:
Grâce à cette méthode, il sera possible de trouver facilement le compte responsable de l’opération sur l’enregistrement, permettant ainsi soit d’identifier immédiatement la cause soit d’affiner considérablement la recherche.
Pour mettre en place et exploiter l’audit des créations, modifications ou enregistrements DNS dans une zone intégrée AD, il est nécessaire de procéder à trois opérations :
Activez l’audit de changement des objets de l’annuaire :
Note: Avant d'activer l'audit, assurez-vous que l'enregistrement circulaire est activé ou que vous disposez de suffisamment d'espace disque. Pour plus d'informations sur l'activation de l'audit voir l'article technet http://technet.microsoft.com/en-us/library/cc731607(v=ws.10).aspx
Dans la stratégie des contrôleurs de domaine, naviguez jusqu’à Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > DS Access puis activez l’audit en paramétrant la sous-catégorie Audit Directory Service Changes :
Mettez ensuite en place l’audit sur la zone concernée.
Dans la console dnsmgmt.msc, naviguez jusqu’à la zone à auditer puis faites un clic droit sur la zone Properties > Security > Advanced > Auditing et cliquez sur Add.
Renseignez alors les champs comme indiqué sur la capture ci-dessous :
Security Principal : Everyone
Type : All
Permissions : Write All properties, Delete, Delete subtree, Create all child objects, Delete All child objects
Note: Les permissions Create dnsNode et Delete dnsNode sont implicites des permissions Created all child Objects et Delete all Child objects, il n’est donc pas nécessaire de les selectionner par la console ADSIedit.
Une fois l’audit activé et la stratégie de groupe rafraîchie (vous pouvez accélérer le processus en lançant la commande gpupdate /force sur le contrôleur de domaine à auditer), les enregistrements des actions sur la zone DNS sont actifs.
Lors de la prochaine occurrence de l’évènement il faudra alors, avant de recréer l’enregistrement (car sinon vous risquez de le réanimer), déterminer depuis quel serveur il a été supprimé comme détaillé dans l’étape suivante.
2. Identifiez le contrôleur de domaine originaire de la modification de l’objet dnsNode :
Pour cela :
Pour ce premier exemple, il s'agit de l'enregistrement xvcwcv. Cet enregistrement est présent dans la zone contoso.com, elle-même stockée dans la partition DomainDnsZones. Si votre ou vos enregistrements manquants se situent dans une autre partition applicatibe (par exemple ForesDnsZones), vous devrez adapter le DN donné en exemple dans les commandes qui suivent afin de le faire correspondre à la réalité. 2. Puis validez que l’enregistrement a bien été tombstoned. Il existe plusieurs méthodes :
Pour ce premier exemple, il s'agit de l'enregistrement xvcwcv. Cet enregistrement est présent dans la zone contoso.com, elle-même stockée dans la partition DomainDnsZones. Si votre ou vos enregistrements manquants se situent dans une autre partition applicatibe (par exemple ForesDnsZones), vous devrez adapter le DN donné en exemple dans les commandes qui suivent afin de le faire correspondre à la réalité.
2. Puis validez que l’enregistrement a bien été tombstoned. Il existe plusieurs méthodes :
Get-ADobject -searchbase "dc=contoso.com,cn=microsoftDNS,dc=domaindnszones,dc=contoso,dc=com" -filter {name -eq 'xvcwcv'} -properties * | findstr dNSTombstoned
vous permettra par exemple de savoir si l’enregistrement xvcwcv (remplacer le DN donné en exemple par celui de l’enregistrement manquant) présent dans la zone contoso.com (à remplacer) hébergée dans la partition applicative DomainDnsZones (à remplacer si nécessaire) a bien été supprimé ; dNSTombstoned : True
il faut donc adapter les variables à votre environnement et à l’enregistrement que vous recherchez.
De la même façon, la commande
Get-ADobject -searchbase "dc=contoso.com,cn=microsoftDNS,dc=domaindnszones,dc=contoso,dc=com" -filter * -properties * | Where-Object {$_.dnstombstoned -eq 'true'} | Select-Object dnstombstoned,name
permettra de connaître tous les enregistrements supprimés récemment.
Note: Cette méthode nécessite cependant que le module Powershell Active-Directory soit installé sur votre contrôleur de domaine ou station d'administration et que les service Active Directory Web Services soit opérationnel. Plus d'informations sur l'interaction entre Powershell et Active Directory ici http://technet.microsoft.com/fr-fr/library/dd378937(v=ws.10).aspx
Il est également possible de vérifier cela avec ADSIedit.msc en naviguant dans la partition hébergeant la zone et en vérifiant graphiquement l’attribut dnsTombstoned de l’objet dnsNode contenant l’enregistrement :
A présent que nous avons identifié un enregistrement manquant, la commande repadmin /showobjmeta contosodc1 "dc=xvcwcv,dc=contoso.com,cn=microsoftdns,dc=domaindnszones,dc=contoso,dc=com" nous permettra de connaître le contrôleur de domaine à l’origine de la modification de l’enregistrement dans la zone, où contosodc1 est le nom d’un contrôleur de domaine à interroger et dc=xvcwcv,dc=contoso.com,cn=microsoftdns,dc=domaindnszones,dc=contoso,dc=com le dN de l’objet dnsNode hébergeant l’enregistrement DNS supprimé.
A présent que nous avons identifié un enregistrement manquant, la commande
repadmin /showobjmeta contosodc1 "dc=xvcwcv,dc=contoso.com,cn=microsoftdns,dc=domaindnszones,dc=contoso,dc=com"
nous permettra de connaître le contrôleur de domaine à l’origine de la modification de l’enregistrement dans la zone, où contosodc1 est le nom d’un contrôleur de domaine à interroger et dc=xvcwcv,dc=contoso.com,cn=microsoftdns,dc=domaindnszones,dc=contoso,dc=com le dN de l’objet dnsNode hébergeant l’enregistrement DNS supprimé.
Sur la capture d’écran, nous pouvons donc constater que l’attribut dNSTombstoned a été modifié depuis CONTOSODC1 à 20 :49 le 19/01/2014.
3. Consultez le journal des évènements du contrôleur de domaine identifié
Une fois l’enregistrement et le contrôleur de domaine identifiés, consultez les entrées du journal des évènements d’audit sur le contrôleur de domaine à l’origine de la modification et recherchez les évènements 5136 correspondant à l’heure de modification :
Pour reprendre notre exemple de disparition de l'enregistrement xvcwcv.contoso.com voici ce que nous apprend le journal des évènements de CONTOSODC1 à ce sujet:
A directory service object was modified. Subject: Security ID: CONTOSO\XVCWCV$ Account Name: XVCWCV$ Account Domain: CONTOSO Logon ID: 0x1E969B Directory Service: Name: contoso.com Type: Active Directory Domain Services Object: DN: DC=xvcwcv,DC=contoso.com,cn=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com GUID: DC=xvcwcv,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com Class: dnsNode Attribute: LDAP Display Name: dNSTombstoned Syntax (OID): 2.5.5.8 Value: TRUE Operation: Type: Value Added Correlation ID: {d9022d09-9c03-4ead-af58-c50e810aeaab} Application Correlation ID: -
A directory service object was modified.
Subject:
Account Name: XVCWCV$
Account Domain: CONTOSO
Logon ID: 0x1E969B
Directory Service:
Name: contoso.com
Type: Active Directory Domain Services
Object:
DN: DC=xvcwcv,DC=contoso.com,cn=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com
GUID: DC=xvcwcv,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com
Class: dnsNode
Attribute:
LDAP Display Name: dNSTombstoned
Syntax (OID): 2.5.5.8
Value: TRUE
Operation:
Type: Value Added
Correlation ID: {d9022d09-9c03-4ead-af58-c50e810aeaab}
Application Correlation ID: -
Cet évènement 5136 nous informe donc que le compte machine XCVXWCV$ a modifié la valeur de l'attribut dNSTombstoned en la passant à TRUE. A partir de là le diagnostic s'oriente clairement vers une mise à jour dynamique avec un TTL à zero car nous savons que c'est le compte machine lui-même qui a supprimé son propre enregistrement.
Prenons également l'exemple de la création et de la suppression manuelle d'un enregistrement, nommé NewRR par l'administrateur :
Cet évènement correspond à la création du contenu de l’enregistrement.
A directory service object was modified. Subject: Security ID: CONTOSO\administrator Account Name: Administrator Account Domain: CONTOSO Logon ID: 0x33404 Directory Service: Name: contoso.com Type: Active Directory Domain Services Object: DN: DC=newRR,DC=contoso.com,cn=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com GUID: DC=newRR,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com Class: dnsNode Attribute: LDAP Display Name: dnsRecord Syntax (OID): 2.5.5.10 Value: <Binary> Operation: Type: Value Added Correlation ID: {863e3db1-03f7-4fa0-a588-24b1a95c15eb} Application Correlation ID: -
Security ID: CONTOSO\administrator
Account Name: Administrator
Logon ID: 0x33404
DN: DC=newRR,DC=contoso.com,cn=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com
GUID: DC=newRR,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com
LDAP Display Name: dnsRecord
Syntax (OID): 2.5.5.10
Value: <Binary>
Correlation ID: {863e3db1-03f7-4fa0-a588-24b1a95c15eb}
Lorsque l’on supprime ce même record, voici l’un des 3 évènements 5136 générés qui correspond à la suppression du contenu de l’enregistrement (attribut dnsRecord) :
A directory service object was modified. Subject: Security ID: CONTOSO\administrator Account Name: Administrator Account Domain: CONTOSO Logon ID: 0x33404 Directory Service: Name: contoso.com Type: Active Directory Domain Services Object: DN: DC=newRR,DC=contoso.com,cn=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com GUID: DC=newRR,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com Class: dnsNode Attribute: LDAP Display Name: dnsRecord Syntax (OID): 2.5.5.10 Value: <Binary> Operation: Type: Value Deleted Correlation ID: {7b955f29-b21c-4d33-a7a2-19e3d6f06172} Application Correlation ID: -
Type: Value Deleted
Correlation ID: {7b955f29-b21c-4d33-a7a2-19e3d6f06172}
Ici donc, le compte administrator a supprimé l’enregistrement NewRR et l’évènement correspond à la suppression du contenu de l’enregistrement. Il existe également un évènement 5136 pour la modification de l’attribut dNSTOmbsoned, l’un comme l’autre nous renseigneront sur le compte ayant fait la modification.
Note : Si lors d'une investigation sur une suppression vous constatez que le serveur à l’origine de la modification est le serveur sur lequel le scavenging est activé et que le compte utilisé pour modifier l’enregistrement est le compte machine du serveur, tentez de relier l’heure de modification de l’attribut dnsTombstoned ou dnsRecord à un event 2501 dans le journal des évènements DNS.
Je vous conseille par ailleurs ce post sur le scavenging DNS http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx . Vous noterez que l’auteur recommande un seul serveur opérant le scavenging notamment pour une plus grande simplicité en cas de troubleshooting.
La recommandation actuelle est cependant d’utiliser deux serveurs car cela permet d’obtenir une redondance de service en cas de panne de l’un des serveurs. Toutefois un seul serveur est acceptable et cela simplifiera dans votre cas la résolution du problème si celui-ci est lié au scavenging.
Et pour les zones autorisant les enregistrement non sécurisés ça marche aussi ?
Malheureusement pour les zones non sécurisées la méthode se révèle beaucoup moins utile. En effet le comportement par défaut d'un client DNS, même s'il supporte les mises à jour sécurisées par Kerberos, est de tenter en premier lieu une mise à jour non sécurisée.
Autrement dit, si vous autorisez les mises à jour non sécurisées dans une zone intégrée à l'annuaire, aucun enregistrement créé ne sera sécurisé, n'importe quel client DNS pourra requêter une modification sans authentification préalable et les objets dnsNode seront donc directement modifiés par le contrôleur de domaine qui reçoit la demande de mise à jour.
Ainsi l’audit ne vous serait d’aucune utilité dans le cas où les suppressions seraient issues d’une demande de mise à jour dynamique.
Plus que jamais donc, la mise en place de mises à jour DNS sécurisées n'est pas une bonne pratique pour rien car non seulement elle réduit l'exposition de la zone à certains types d'attaques ou de dysfonctionnements mais en plus, dans le cas où vous seriez malgré tout victime de disparitions spontanées d'enregistrements, elle vous permettra également d'en identifier plus rapidement la cause comme nous venons de le voir ensemble.
Pour finir, sachez qu'à Microsoft France nous proposons un workshop 100% en Français sur DNS pour nos clients Premier. Au programme les fondametaux DNS revus et entièrement expliqués en profondeur, l'administration, la sécurité, la sauvegarde/restauration et bien d'autres sujets encore…
Si vous êtes intéressé et que vous êtes client Premier, n'hésitez pas à demander à votre TAM de vous inscrire à cet excellent workshop.
François Petit
PFE
Le produit AADSync est actuellement en version beta, il est destiné à synchroniser plusieurs forêts AD de votre entreprise vers le cloud.
Ce qui n’est pas le cas avec DirSync, qui actuellement, ne permet de synchroniser qu’une forêt AD vers le cloud.
Les produits nécessaires pour installer AADSync sont : SQL Express, .NET Framework 4.0, powerShell V3, Windows 2008 ou version plus récente.
. Pour l’instant, la version bêta actuelle ne permet pas de faire de la synchronisation des mots de passe.
. La fréquence de synchronisation automatique des objets est de une fois toutes les 3 heures, mais vous pouvez forcer la synchronisation manuellement.
. Dans AADSync, vous pouvez choisir l’attribut à synchroniser vers le cloud.
Pour plus d’information, je vous invite à lire le lien suivant :
http://social.technet.microsoft.com/wiki/contents/articles/24059.aadsync-content-roadmap.aspx
Cordialement,