PI Services

La nouvelle version d’office Communication Serveur 2007R2 nommé Lync Server 2010 est actuellement RTM et devrait être disponible début décembre sur le portail Technet.

Cette version apporte sont lots de nouveautés et un nouveau client de communication. Ce client subit une politique configurée par l’administrateur, par défaut une politique est appliquer a tous les client, elle permet notamment aux utilisateurs de positionner une photo .Cette politique est nommée Global dans LCP (Lync Control Panel). Voici donc a quoi peut ressemblé le client une fois la photo mise en place:

Avec la centralisation de la politique de gestion des client, il est assez simple de pouvoir interdire aux utilisateurs ou à certains de positionner une photo dans leur client Lync.

Pour cela une peu de Powershell pour Lync:

Tout d’abord nous récupérons les différents paramètres de la politique Global avec la commande:

Get-CsClientPolicy –identity Global

Une fois la politique affichée nous récupérons le paramètre aàmodifier:

DisplayPhoto

Ce paramètre peut prendre 3 valeurs différentes:

• AllPhotos
• NoPhoto
• PhotosFromADOnly

Ici je souhaite que mes utilisateurs ne puisse pas afficher les photos de leurs contacts dans le client Lync. Je positionne donc le paramètre NoPhoto. Pour cela la commande PowerShell Lync suivant est utilisé:

Set-CsClientPolicy Global –DisplayPhoto NoPhoto

Suite a cette modification de la politique Global s’appliquant a tous mes utilisateurs, une déconnexion (sign-Out) puis reconnexion (sign-in) me permet de vérifier que la politique c’est appliquée à mes utilisateurs:

D’autre part la politique ne permettant plus a mes utilisateurs à partir des option du client d’afficher les photos, le menu du client est lui aussi modifié pour ne pas lui permettre de forcer cet affichage:

  Enfin une fois la configuration Global reconfigurer avec la commande

Set-CsClientPolicy Global –DisplayPhoto Allphéeos

L’ensemble des paramètres sont de nouveau disponible et l’utilisateur peut modifier son affichage si il le souhaite:

Cette configuration permet aux utilisateurs qui changerait de version de ne pas avoir une modification d’affichage trop importante entre OCSR1/R2 et Lync Server 2010.

Lors de l’organisation de conférence, les premiers échanges consiste à indiquer à tous les participants les règles de la conférence. En fonction des conditions d’écoute de chacun l’information peut ne pas parvenir aux participants et aucune acceptation de ces règles n’est demandée explicitement.

Dans Lync Serveur, il est possible d’ajouter un disclaimer qui s’affichera pour tous les utilisateurs qui souhaite intégrer la conférence.

Par défaut le disclaimer est vide et donc aucune page ne s’affiche pour rejoindre une conférence:

Get-CsconferenceDisclaimer

Afin de pouvoir afficher un message avant la conférence il est nécessaire de saisir les paramètres de CsConfernecingDisclaimer:

Set-CsConferencingDisclaimer Global –Header “Disclaimer de PI Services” –body “Votre message de disclaimer”

Une fois le header et le Body valider, les paramètres sont modifiés sur le disclaimer Global.

Get-CsconferenceDisclaimer

Une fois le paramètre positionné, nous allons créer une conférence, pour cela seul le client lync est nécessaire (Live Meeting n’est pas un pré-requis)

Lancer l’option Dial-in Conferencing settings pour récupérer votre adresse d’organisation de conférence:

Une fois authentifié vous accéder à vos informations d’organisation de conférence via Lync Server 2010:

Il ne vous reste qu’a communiquer votre adresse de conférence (par defaut elle commence par https://meet.mondomaine.fr/).

Votre interlocuteur sera invité a rejoindre la conférence par différent moyen:

Enfin le disclaimer apparait et nécessite la validation pour poursuivre l’accès à la conférence:

Les utilisateurs de LWA (Lync Web Application) sont aussi sujet à ce disclaimer qu’ils soient Invité ou membre de la société.

Bonne conférence avec Lync Server 2010!

Contexte:

Lors de la mise en œuvre d’une infrastructure exchange 2010 pour un grand compte, il m’est arrivé de devoir activer plus de 20 licences Exchange 2010. L’activation de ces nombreux serveurs est fastidieuse et peut engendrée des erreur de saisie.

Solutions possibles:

Tous vos serveurs sont en version Standard ou en version Enterprise:

Get-ExchangeServer | Set-ExchangeServer -ProductKey ‘Clef produit’

Les versions sont différentes en fonction du rôle:

Get-ClientAccessServer | Set-ExchangeServer -ProductKey ‘Clef produit’

Get-TransportServer | Set-ExchangeServer –ProductKey ‘Clef produit’

Get-MailboxServer | Set-ExchangeServer -ProductKey ‘Clef produit’

Get-UMserver | Set-ExchangeServer –ProductKey ‘Clef produit’

Conclusion:

L’activation des serveurs est simplifié avec cette commande et permet un gain de temps lors du déploiement de nombreux serveurs de messagerie Exchange 2010.

A noté que cette commande est fonctionnelle avec Exchange 2007.

La taille des sources de cette mise a jour (un peu plus d’1 Gb) qui contiens les mises a jours des cumulative update précédents, s’explique aussi par la présence de composants propre a la supervision Unix/linux (Cross Platform).

Indépendamment des correctifs inclus, cette mise a jour apporte un nouvel assistant pour la supervision des applications issus de la plate-forme de service en ligne Microsoft Azur, ainsi que des fonctions d’utilisation de paramètres pour la supervision avancée des sites web.

Les sources de cette mise a jour sont disponible ici:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9f1e1154-52ae-42df-aeea-b3ee83247e6a

Pour une description complète et un retour d’expérience précieux sur cette mise a jour:

http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/81313/Default.aspx

Ce qui avait été annoncé comme non supporté fait finalement l’objet d’une procédure particulière utilisant l’outil de création des bases SCOM, DBCreateWizard.exe inclu dans les sources de SCOM.

Pour plus de détails rendez vous sur http://support.microsoft.com/kb/2425714

La problématique

Lors du déploiement d'une Appliance Symantec Brightmail Gateway un certificat numérique auto-signé est automatiquement généré et assigné à l'interface Web du rôle Control Center.

La principale conséquence de cette configuration est l'apparition systématique d'une fenêtre d'avertissement lors de la connexion à l'interface Web d'administration (cf. capture d'écran ci-dessous).

De plus l'URL du navigateur apparaît en rouge pour rappeler que le certificat SSL utilisé pour chiffrer les données est invalide.

Cela n'est pas gênant lorsque seule une population d'administrateur se connecte à l'interface Web. Cependant, lorsque l'accès utilisateur à la quarantaine est activée, il devient nécessaire de corriger ce comportement.

Cette configuration doit être effectuée en plusieurs étapes :

1) Configuration de l'URL d'accès à la quarantaine
2) Import de l'autorité de certification interne dans l'Appliance
3) Génération d'une requête de certificat (CSR)
4) Validation de la requête auprès de l'autorité de certification interne (ou externe)
5) Import du certificat signé par l'autorité dans l'Appliance
6) Positionnement du certificat sur l'interface Web

Procédure à suivre

1) Configuration de l'URL d'accès à la quarantaine

La première étape consiste à définir, puis à configurer l'URL d'accès à la quarantaine utilisateur. Pour cela il faut se connecter à l'interface Web d'administration en tant qu'administrateur, cliquer sur l'onglet Spam, puis sur le lien Quarantine Settings dans le menu de gauche.

On peut ensuite spécifier l'URL d'accès à la quarantaine dans le champ Spam Quarantine Login URL. Dans l'exemple ci-dessous l'URL retenue est la suivante :

• https://sbg.piservices.fr:41443/brightmail

Remarque : L'accès utilisateur à la quarantaine nécessite également que l'option Administrator-only Quarantine soit décochée et donc que l'accès à un annuaire soit configuré (pour l'authentification LDAP). De plus une entrée DNS doit également être créée pour effectuer la correspondance entre le FQDN de l'interface Web (exemple : sbg.piservices.fr) et l'adresse IP du control center.

2) Import de l'autorité de certification interne dans l'Appliance

Dans l'hypothèse où l'on souhaite utiliser un certificat émis par une autorité de certification interne, il faut impérativement insérer le certificat de l'autorité de certification racine dans le magasin Certificate Authority de l'Appliance.

Pour cela l'administrateur doit se connecter à l'interface Web d'administration, cliquer sur l'onglet Administration, puis sur le lien Certificates dans le menu de gauche. Il faut ensuite sélectionner l'onglet Certificate Authority, puis cliquer sur le bouton Update.

L'assistant propose alors d'injecter un certificat présent localement sur le poste de l'administrateur. Ce certificat doit respecter le format PEM (CER encodé en base64).

Remarque : Dans le cas où l'autorité de certification interne est issue du monde Microsoft (serveurs sous Windows Server 2003, 2003 R2, 2008 ou 2008 R2), les formats généralement utilisés sont les formats CER ou CRT. Pour les convertir au format PEM un utilitaire de conversion comme Crypto4PKI peut être utilisé.

3) Génération d'une requête de certificat (CSR)

L'étape suivante consiste à créer une requête de demande de certificat dans l'interface Web d'administration. Pour cela il faut aller dans l'onglet TLS & HTTPs Certificates, puis cliquer sur le bouton Add.

Dans l'assistant de création de la requête il faut sélectionner Certification Authority Signed dans le type de certificat, renseigner le nom commun qui doit correspondre à l'URL d'accès à la quarantaine (ici "sbg.piservices.fr") ainsi que tous les champs descriptifs demandés.

Le bouton Request permet ensuite de générer la demande de certificat ou CSR (Certificate Signing Request).

La requête obtenue doit ensuite être conservée en mémoire (cf. capture d'écran ci-dessous).

Suite à cette manipulation le certificat apparaît comme étant Requested dans l'interface Web.

4) Validation de la requête auprès de l'autorité de certification interne

La requête de certificat doit ensuite être validée et signée numériquement par l'autorité de certification interne. Si il s'agit d'une autorité de certification Microsoft, l'une des méthodes consiste à se connecter à l'interface Web d'administration (l'URL est généralement du type https://server/certsrv).

Pour commencer l'administrateur doit sélectionner le lien Request a certificate, puis advanced certificate request et enfin Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

Dans la page Submit a Certificate Request or Renewal Request il faut insérer la requête précédemment générée, sélectionner le modèle de certificat Web Server et enfin cliquer sur le bouton Submit.

Si l'autorité de certification est de type "entreprise" et si le compte utilisateur possède les bonnes autorisations alors un certificat signé numériquement au format CER est immédiatement émis par l'autorité de certification (dans le cas d'une autorité de certification "autonome", l'émission du certificat doit être validée manuellement dans la console MMC Autorité de certification).

Remarque : Le certificat émis étant au format CER, il doit être converti au format PEM pour pouvoir être utilisé au sein de l'interface Web Brightmail.

5) Import du certificat signé par l'autorité dans l'Appliance

Pour importer le certificat au format PEM dans l'interface Web Brightmail, il faut cliquer sur l'onglet Administration, puis sur le lien Certificates et enfin sur le bouton Import.

Suite à l'opération d'import un message indique que le certificat a été correctement importé et le certificat apparaît comme étant disponible (available).

6) Positionnement du certificat sur l'interface Web

La dernière étape consiste à positionner le certificat sur l'interface Web d'administration du control center. Pour cela il faut cliquer sur l'onglet Administration, puis sur le lien Control Center.

Dans la page Control Center Settings, il faut ensuite cliquer sur l'onglet Certificates, puis sélectionner le nouveau certificat dans la liste déroulante User interface HTTPs certificate.

Une fois cette dernière modification opérée, aucun message d'erreur n'est généré dans les navigateurs lors de l'accès à l'interface Web et l'URL du site ne s'affiche plus sur fond rouge mais sur un fond blanc ou vert (en fonction du type de certificat utilisé).

Ce billet a pour objectif de référencer les versions des différentes extensions de schéma disponibles pour Active Directory, Exchange et LCS/OCS.

Remarque : Les versions intermédiaires (Beta, RC, CTP...) des produits utilisent des numéros de versions spécifiques qui ne sont pas indiqué dans ce billet (seules les versions finales ou RTM sont prises en compte).

Extensions de schéma Active Directory

Le tableau ci-dessous liste les différentes versions de schéma existantes pour l'annuaire Active Directory.

Extensions de schéma Exchange

Le tableau ci-dessous liste les différentes versions de schéma existantes pour la plateforme de messagerie Exchange.

Extensions de schéma LCS/OCS

Le tableau ci-dessous liste les différentes versions de schéma existantes pour le logiciel de collaboration Office Communication Server (OCS).

Comment vérifier manuellement une version de schéma ?

Pour vérifier manuellement la version du schéma Active Directory, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut objectVersion sur le conteneur "CN=Schema,CN=Configuration,DC=domaine,DC=local"
• Exécuter la commande suivante :

dsquery.exe * "CN=Schema,CN=Configuration,DC=domaine,DC=local" -scope base -attr objectversion

Pour vérifier manuellement la version du schéma Exchange, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut rangeUpper sur l'attribut ms-Exch-Schema-Version-Pt
• Exécuter la commande suivante :

dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=domaine, dc=local -scope base –attr rangeUpper

Pour vérifier manuellement la version du schéma OCS, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut rangeUpper sur l'attribut ms-RTC-SIP-SchemaVersion
• Exécuter la commande suivante :

dsquery.exe * CN=ms-RTC-SIP-SchemaVersion,CN=Schema,CN=Configuration, DC=domaine,DC=com -scope base -attr rangeupper

L’installation de SAV 10 demande des pré-requis d’installation.

Avant d'installer tous les paquets, vous devez installer Sun JRE version 1.4.2 ou supérieur avec la version illimitée de JCE. Par défaut, JRE est livré avec la version de cryptographie forte de JCE, mais LiveUpdate nécessite la version illimitée. Si vous voulez utiliser l'interface graphique, vous devez également installer un environnement X11.

Il y a des pré-requis supplémentaires pour certains noyaux Linux (Fedora et Debian). Red Hat étant nativement supporté, nous ne détaillerons pas ces pré-requis.

Ils sont disponibles sur le site de Symantec à l’addresse : http://service1.symantec.com/support/ent-security.nsf/docid/2010062217010148.

L'installation des packages sous Linux doit respecter un ordre précis :

1. SAV

2. savap (ou savap-x64 pour la version 64-bit)

3. savjlu

4. savui

En premier, le noyau de SAV : SAV

Il contient le noyeau : « savap »

Il utilise une fonctionalité de recherche d’OS et de composants dont il a besoin.

Attention, au moment du démarrage du système, SAV pour Linux détecte la distribution Linux exécutée et assemble une liste des modules du noyau.

« Using a "fuzzy match" algorithm, it will go through the list of candidates, one at a time, until it finds one that can be loaded by the Linux OS. »

L’utilisation d'un algoritme à adéquation partielle ("fuzzy match") permet de lister les composants un à un, jusqu'à ce qu'il trouve celui qui peut être chargé par le système d'exploitation Linux.

Si aucun des systèmes linux n’est détecté comme compatible et ne peut être chargé dans le noyau, SAV pour Linux va écrire un message d'erreur dans la console et enregistrer l'erreur dans le journal des messages du système (/var/log/messages ou /var/log/syslog).

Les deux autres paquets contiennent Java et les fichiers LiveUpdate GUI.

Une fois l'installation terminée, vérifiez que les démons suivants sont en cours d'exécution:

1. rtvscand

2. symcfgd

Si ces processus ne sont pas en cours d'exécution, vous pouvez les démarrer comme suit:

1. # / Etc / init.d / start rtvscand

2. # / Etc / init.d / start symcfgd

Pour rappel :

Doc Sav 10 linux : Lien FTP

Pour préconfigurer le package de SAV 10 for Linux, il faut utiliser « ConfigEd.exe ».

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007100513224548?Open&seg=ent

Cette application demande la présence d’un SAV sur le poste qui l’exécute.

Note : il est possible de passer des commandes d’exclusion de Scan, directement sur le serveur une fois celui ci installé :

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009072917021448?Open&seg=ent

Pour info :

un script et un fichier texte commençant par #!/bin/sh

Exemple de script pour faire une exclusion :

#!/bin/sh

symcfg add -k '\Symantec Endpoint Protection\AV\Storages\FileSystem\RealTimeScan' -v HaveExceptionDirs -d 1 -t REG_DWORD

symcfg add -k '\Symantec Endpoint Protection\AV\Storages\FileSystem\RealTimeScan\NoScanDir' -v /my/path/to/folder1 -d 1 -t REG_DWORD

/my/path/to/folder1 étant le chemin du dossier à exclure.

(Lu depuis http://www.tuteurs.ens.fr/unix/shell/script.html )

ensuite il faut le rendre exécutable chmod u+x lenomdufichier et pour le lancer soit : ./lenomdufichier ou sh lenomdufichier

Cette grosse faille de sécurité a été publiée par Microsoft le 16 juillet dernier ( CVE-2010-2568 ). Elle exploite le mode de fonctionnement des raccourcis ( ".LNK" ) sur tous les OS Windows. Bien sûr la mise à disposition du patch correspondant sera annoncée dans le bulletin de sécurité :http://www.microsoft.com/technet/security/advisory/2286198.mspx.

L’exploitation de cette faille se traduit par le fait, qu’un malware puisse s’exécuter par le biais du détournement du mécanisme d’affichage d’icône.

Cette vulnérabilité est exploitable localement par disque amovible ou via des partages réseaux et WebDAV

Il n'existe pas de correctif à ce jour. Mais en attendant des solutions de contournement recommandées par Microsoft peuvent-être mises en place.

La désactivation de l'affichage d'icône pour les raccourcis peu ainsi limiter les risques d’exploitation de cette faille. Cette solution affiche les icônes en blanc par défaut. Pour se faire il est nécessaire depuis l’éditeur de registre, de rechercher dans la ruche HKEY_CLASS_ROOT, IconHandler afin de modifier sa valeur par défaut par 0 après l’avoir exporté pour revenir à la valeur précédente dès la sortie d’une mise à jour.

Autre solution de contournement la désactivation du service WebClient se fait en passant par le gestionnaire de l’ordinateur ou en exécutant services.msc

Enfin troisième solution le blocage du téléchargement des fichiers LNK et PIF depuis Internet est recommandé. 

La liste des systèmes Windows concernés et supportés s'étend de Windows XP SP3 à Windows Serveur 2008R2.

Notez que des éditeurs d’antivirus (Sophos, Eset) ont déjà répertorié Stuxnet depuis mi-juillet exploitant cette vulnérabilité.

MAJ: Le 3 Aout Microsoft apporte une réponse par la mise en ligne de l'update KB2286198 annoncé dans le bulletin de sécurité suivant http://www.microsoft.com/technet/security/bulletin/MS10-046.mspx

Beaucoup de programmes TCP/IP comme Ping et FTP utilisent la fonction WinSock INET_ADDR() :

unsigned long inet_addr( __in const char *cp );

pour convertir les adresses IPv4 du format chaine de caractère avec séparateur ”.” dans un format IN_ADDR qui n’est qu’une structure.

typedef struct in_addr { union { struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b; struct { u_short s_w1,s_w2; } S_un_w; u_long S_addr; } S_un; } IN_ADDR, *PIN_ADDR, FAR *LPIN_ADDR;

Toute adresse IPv4 sera formatée dans cette structure sous le format d’un entier long non signé (u_long).

La fonction INET_ADDR accepte les chaines de caractères au format suivant :

• a.b.c.d
• a.b.c
• a.b
• a

Les différentes parties qui définissent l’adresse IP dans son format caractère avec séparateur “.” peuvent avoir des valeurs décimales , octales ou hexadécimales.

Ainsi pinger l’adresse 172.19.0.40 revient à pinger  l’adresse 0254.023.0.050 en octal et l’adresse 0xAC.0x13.0.0x28 en hexadécimal.

172.19.0.40

0254.023.0.050

0xAC.0x13.0.0x28

Lors du traitement de la chaine de caractère en entrée, la fonction INET_ADDR traitera les nombre selon les règles suivantes :

• Tout nombre commençant par  0x ou 0X sera traité comme un chiffre hexadécimal
• Tout nombre commençant par 0 sera traité comme étant un nombre octal
• Les autres cas seront traité comme des nombres décimaux.

Ainsi il faut faire attention à ne pas utiliser un Zéro à gauche au niveau d’une partie de l’adresse IP si vous voulez la pinger car la partie qui commence par zéro sera traité comme étant un nombre octal et le Ping sera dirigé vers une autre adresse qui ne correspond pas à celle que vous avez tapé.