Archive for January, 2017


Aucune entrée Apple Mobile Device USB Driver affichée

  1. Déconnectez votre appareil de l’ordinateur.
  2. Effectuez une capture d’écran en appuyant simultanément sur le bouton principal et sur le bouton Marche/Veille (l’écran doit alors clignoter brièvement).
  3. Reconnectez l’appareil à votre ordinateur.
  4. Si l’une des sections suivantes s’affiche dans le Gestionnaire de périphériques (device manager en Anglais), agrandissez-les :
    • Périphériques d’images
    • Autres périphériques
    • Appareils mobiles
    • Contrôleurs de bus USB

Recherchez à présent l’entrée qui reconnaît l’appareil en tant qu’appareil photo. Vous devriez voir s’afficher « Apple iPhone », « Apple iPad » ou « Apple iPod ». Cliquez avec le bouton droit de la souris sur l’entrée de l’appareil, puis mettez manuellement à jour le pilote Apple Mobile Device USB Driver.

Si seule l’entrée Périphérique inconnu s’affiche :

  1. Cliquez avec le bouton droit de la souris sur l’entrée Périphérique inconnu.
  2. Choisissez Propriétés dans le menu contextuel et cliquez sur l’onglet Détails.
  3. Dans le menu déroulant, sélectionnez Numéros d’identification du matériel.
  4. Si l’identifiant ne commence pas par USB\VID_0000&PID_0000, rendez-vous dans le Gestionnaire de périphériques et faites un clic droit sur l’entrée Périphérique inconnu, puis mettez manuellement à jour Apple Mobile Device USB Driver.
  5. Si l’identifiant commence par USB\VID_0000&PID_0000, suivez les instructions ci-dessous.
  6. Déconnectez l’appareil et débranchez tous les périphériques USB de l’ordinateur.
  7. Éteignez, puis rallumez l’ordinateur.
  8. Reconnectez l’appareil et testez chaque port USB pendant environ 30 secondes pour vérifier si l’appareil est reconnu.
  9. Effectuez un test avec un autre câble Apple 30 broches vers USB ou un autre câble Lightning vers USB fiable, le cas échéant.

Si le problème persiste, contactez l’assistance Apple.

Mise à jour manuelle du pilote Apple Mobile Device USB Driver

Si l’une des sections ci-dessus vous redirige vers cette section, il se peut que vous ayez déjà effectué un clic droit sur une entrée du Gestionnaire de périphériques. Effectuez à présent la procédure suivante :

  1. Choisissez Mettre à jour le pilote logiciel.
  2. Sélectionnez « Rechercher un logiciel pilote sur mon ordinateur ».
  3. Sélectionnez « Me laisser choisir parmi une liste de pilotes de périphériques sur mon ordinateur ».
  4. Cliquez sur le bouton Disque fourni. Si cette option ne s’affiche pas, choisissez une catégorie d’appareil, telle que Téléphone mobile ou Périphérique de stockage, si disponible dans la liste.
  5. Cliquez sur Suivant. Le bouton Disque fourni devrait s’afficher.
  6. Effectuez une recherche dans C:\Program Files(x86)\Common Files\Apple\Mobile Device Support\Drivers (si vous avez un PC sous Windows 32bit) ou C:\Program Files\Common Files\Apple\Mobile Device Support\Drivers  si vous avez un Windows 10 64bit .
  7. Double-cliquez sur le fichier usbaapl. Si vous utilisez une version 64 bits de Windows, ce fichier porte le nom de « usbaapl64 ». Si le fichier « usbaapl64 » ne s’y trouve pas ou s’il n’existe aucun dossier Drivers,
  8. Dans la fenêtre Disque fourni, cliquez sur Ouvrir, sur Suivant, puis sur Terminer.
  9. Windows installe alors le pilote. Si un message s’affiche, indiquant que le logiciel que vous installez n’a pas été validé lors du test permettant d’obtenir le logo Windows, cliquez sur Continuer quand même. Vous pouvez obtenir de l’aide concernant les autres erreurs et numéros de code d’erreur courants dans cet article Microsoft.
  10. Ouvrez iTunes afin de vous assurer qu’il reconnaît bien votre appareil. Si ce n’est pas le cas, redémarrez le service Apple Mobile Device.

Main resources:

https://technet.microsoft.com/en-us/library/gg398616.aspx?f=255&MSPPError=-2147217396

 

 

Two ways to integrate/federate applications with Azure AD:

Azure marketplace:

https://azure.microsoft.com/en-us/marketplace/active-directory/all/

check if the application exists:

The Microsoft Azure Marketplace is an online store that offers applications and services either built on or designed to integrate with Microsoft’s Azure public cloud.

Else, how to configure single sign-on to applications that are not in the Azure Active Directory application gallery: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-custom-apps

Authentication scenarios for Azure AD:

https://docs.microsoft.com/fr-fr/azure/active-directory/develop/active-directory-authentication-scenarios

Applications integrated with Azure: the access via https://account.activedirectory.windowsazure.com/applications/default.aspx

Integrating applications with Azure AD: https://docs.microsoft.com/fr-fr/azure/active-directory/develop/active-directory-integrating-applications

 

Identity hybrid ports and protocols:

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-ports

 

Azure app gallery:

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-app-gallery-listing

If not pre-packaged in Azure marketplace: Any app that supports SAML 2.0 can be integrated directly with an Azure AD tenant using these instructions to add a custom application.

Provide credentials for a test tenant or account with your application that can be used by the Azure AD team to test the integration.

Provide the SAML Sign-On URL, Issuer URL (entity ID), and Reply URL (assertion consumer service) values for your application, as described here. If you typically provide these values as part of a SAML metadata file, then please send that as well.

Provide a brief description of how to configure Azure AD as an identity provider in your application using SAML 2.0. If your application supports configuring Azure AD as an identity provider through a self-service administrative portal, then please ensure the credentials provided above include the ability to set this up.

Configuring single sign-on to applications that are not in the Azure Active Directory application gallery:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-custom-apps

Note:

Sign On URL (SP-initiated only) – Where the user goes to sign-in to this application. If the application is configured to perform service provider-initiated single sign on, then when a user navigates to this URL, the service provider will do the necessary redirection to Azure AD to authenticate and log on the user in. If this field is populated, then Azure AD will use this URL to launch the application from Office 365 and the Azure AD Access Panel. If this field is ommited, then Azure AD will instead perform identity provider -initiated sign on when the app is launched from Office 365, the Azure AD Access Panel, or from the Azure AD single sign-on URL (copiable from the Dashboard tab).

Issuer URL – The issuer URL should uniquely identify the application for which single sign on is being configured. This is the value that Azure AD sends back to application as the Audience parameter of the SAML token, and the application is expected to validate it. This value also appears as the Entity ID in any SAML metadata provided by the application. Check the application’s SAML documentation for details on what it’s Entity ID or Audience value is. Below is an example of how the Audience URL appears in the SAML token returned to the application

Reply URL – The reply URL is where the application expects to receive the SAML token. This is also referred to as the Assertion Consumer Service (ACS) URL.

 

 

 

 

 

https://gallery.technet.microsoft.com/scriptcenter/Dump-AD-User-Accounts-25ba7ca8

https://gallery.technet.microsoft.com/scriptcenter/Mirror-AD-User-Accounts-2d5594c4

 

 

 

The basics of SMB signing

Server Message Block (SMB) is the file protocol most commonly used by Windows. SMB Signing is a feature through which communications using SMB can be digitally signed at the packet level. Digitally signing the packets enables the recipient of the packets to confirm their point of origination and their authenticity. This security mechanism in the SMB protocol helps avoid issues like tampering of packets and “man in the middle” attacks.

SMB signing is available in all currently supported versions of Windows, but it’s only enabled by default on Domain Controllers. This is recommended for Domain Controllers because SMB is the protocol used by clients to download Group Policy information. SMB signing provides a way to ensure that the client is receiving genuine Group Policy.

SMB signing was introduced in Windows 2000 (at the time it was also ported back to Microsoft Windows NT 4.0 and Microsoft Windows 98). With the introduction of SMB2 in Windows Vista and Windows Server 2008, signing was improved by using a new hashing algorithm (HMAC SHA-256 replaced the old MD5). At that time, the settings were updated to simplify configuration and interoperability (you can find details later in the post). Another important improvement in SMB2 signing is performance. In SMB1, enabling signing significantly decreases performance, especially when going across a WAN. If using SMB2 plus signing with a 1GbE network and a modern CPU, there is limited degradation in performance as compared to SMB1. If using a faster network (like 10GbE), the performance impact of signing will be greater.

https://blogs.technet.microsoft.com/josebda/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2/

If there are multiple valid certificates available in the local computer store, Schannel the Microsoft SSL provider, selects the first valid certificate that it finds store. The LDAP bind may fail if Schannel selects the wrong certificate.

Loading the requested server certificate into the NTDS/Personal certificate store will ensure that the correct server certificate is used for LDAPS

IMPORTANT NOTE:

  • Automatic certificate enrollment (auto-enrollment) cannot be utilized to populate NTDS\Personal certificate store
  • Command line tools are not able to manage certificates in the NTDS\Personal certificate store
  • Certificates should be imported into the NTDS\Personal store and not moved through drag-and-drop in the Certificates snap-in
  • The import process must be conducted on each domain controller

LDAP over SSL (LDAPS) Certificate (MS TechNet)

When exporting the certificate:

  • When prompted, select “Yes, export the private key”
  • Select the “Personal Information Exchange – PKCS #12(.pfx)” format
  • Do not select “Include all certificates in the certificate path” or “Delete the private key if the export is successful”
  • Select “Export all extended properties”

 

This site is not optimized for Internet Explorer version 8 or lower. Please upgrade to a modern browser.

The question is “How do I delegate enabling and disabling Active Directory accounts?”. Unfortunately, these specific operations cannot be individually delegated. The flag that indicates whether a user is enabled or disabled is part of a bitmask called userAccountControl. The vast majority of options in this bitmask are the checkboxes that you see on the account tab of ADUC:

The complete list of what’s stored in the bitmask (copied out of the iads.h header) is below. Most of them should be fairly self explanatory but this MSDN article explains them all. The numbers are the bit which represents this value in the mask (in hex):

  • ADS_UF_SCRIPT = 0x1
  • ADS_UF_ACCOUNTDISABLE = 0x2
  • ADS_UF_HOMEDIR_REQUIRED = 0x8
  • ADS_UF_LOCKOUT = 0x10
  • ADS_UF_PASSWD_NOTREQD = 0x20
  • ADS_UF_PASSWD_CANT_CHANGE = 0x40
  • ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED = 0x80
  • ADS_UF_TEMP_DUPLICATE_ACCOUNT = 0x100
  • ADS_UF_NORMAL_ACCOUNT = 0x200
  • ADS_UF_INTERDOMAIN_TRUST_ACCOUNT = 0x800
  • ADS_UF_WORKSTATION_TRUST_ACCOUNT = 0x1000
  • ADS_UF_SERVER_TRUST_ACCOUNT = 0x2000
  • ADS_UF_DONT_EXPIRE_PASSWD = 0x10000
  • ADS_UF_MNS_LOGON_ACCOUNT = 0x20000
  • ADS_UF_SMARTCARD_REQUIRED = 0x40000
  • ADS_UF_TRUSTED_FOR_DELEGATION = 0x80000
  • ADS_UF_NOT_DELEGATED = 0x100000
  • ADS_UF_USE_DES_KEY_ONLY = 0x200000
  • ADS_UF_DONT_REQUIRE_PREAUTH = 0x400000
  • ADS_UF_PASSWORD_EXPIRED = 0x800000
  • ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION = 0x1000000

Why list all these options? If you delegate a user rights to modify the userAccountControl attribute, you give them rights to set all these other options. If you’re comfortable with this, the steps below show you how to delegate access to the userAccountControl attribute.

In this example, we will grant a group called User Admins rights to modify the userAccountControl attribute on all User objects in the Sales OU. As always, it’s a best practice to never delegate a right to a user but rather to delegate a right to a security group which the user is a member of.

  1. Launch ADSI Edit – start>run>adsiedit.msc
  2. Browse to the Sales OU and open the properties of the OU.
  3. Select the security tab and then click Advanced.
  4. Click Add and enter the name of the group (“User Admins”). At this point your screen should look similar to the following image:

  1. Click OK and then switch to the Properties tab of the ACL editor dialog.
  2. Select “User objects” from the Apply onto dropdown.
  3.  Scroll down to the userAccountControl entry.
  4. Check the Allow checkboxes for Read userAccountControl and Write userAccountControl (technically the Read right is not necessary but I’ve chosen to include it in case default permissions have been modified elsewhere).