SQL Server : Quels comptes de service choisir ?

SQL Server : Quels comptes de service choisir ?

SQL Server est un moteur de base de données fonctionnant en tant que services, c’est-à-dire que vous avez juste à démarrer le serveur pour que l’application démarre. Nul besoin de se connecter au serveur, ni de démarrer un quelconque programme.
 Par contre, ce service, comme tout autre service nécessite un utilisateur pour s’exécuter. Le choix de cet utilisateur est loin d’être anodin, un mauvais choix peut potentiellement être une brèche de sécurité dans l’entreprise, ou vous faire arracher les cheveux de la tête lors de la mise en place de réplications, ou autre système nécessitant de communiquer entre les serveurs.
 En tout vous avez 5 choix pour chacun des services de SQL Server :

• LocalSystem
• LocalService (Windows 2003 et +)
• NetworkService (Windows 2003 et +)
• Compte Utilisateur Local
• Compte Utilisateur du Domaine

 Les autres choix sont volontairement exclus, mais je vous en cite 2 qui sont à proscrire coûte que coûte :

• Invité local ou du domaine
  • Tout simplement déconseillé car ce compte a son profil local recréé à chacune se ses connexion et dispose de droits très limités (à la limite il est fortement bridé et particulièrement depuis Windows 2003) et peu poser des problèmes avec un service. D’une manière générale ou ne donnera jamais moins de privilèges que celui d’utilisateur à un service.
• Administrateur du domaine
  • Dans ce cas, c’est au contraire que les droits accordés sont beaucoup trop élevés. D’une part SQL Server ne nécessite en aucuns cas des privilèges administrateurs sur une machine, mais encore moins sur un domaine. Utiliser ce type de compte de service est une faille de sécurité majeure, toute personne étant sysadmin (login sa entre autres) bénéficie indirectement de ce type de droits et de l’accès total au domaine de l’entreprise.

 Les comptes utilisables et leurs particularités :

• Compte LocalSystem

 Ce compte est un compte prédéfini (BUILTIN) qui existe sous toutes les versions de Windows NT (NT x, 2000, 2003, XP, Vista et 2008).
 C’est en général l’option par défaut dans beaucoup d’installation de SQL Server. SQL Server dispose de permission « administrateur » local de la machine avec ce compte et même un peu plus étant donné que ce compte dispose de quelques privilèges systèmes supplémentaires que n’ont pas les administrateurs.
Ses droits sont locaux uniquement, ce compte n’a pas de réel contexte utilisateur en cas de connexion à une machine distante, c’est une demande d’ouverture de session (null) qui  faites sur celle-ci (qui est en général refusée).
 C’est un assez mauvais choix car il procure des droits très importants à SQL Server et potentiellement à des personnes malveillantes connectées sur ce même serveur de base de données (possibilités entre autres de redémarrer Windows, etc.). SQL Server n’a pas besoin de privilèges aussi élevé, on préfèrera l’une des autres options plus « sécurisé ».

• Compte LocalService (nouveauté Windows 2003)

Ce compte est un compte prédéfini (BUILTIN) qui existe sous toutes les versions de Windows à partir de 2003 / XP (2003, XP, Vista et 2008).
 Ses droits sont ceux d’un utilisateur simple local. Les privilèges dont il dispose sont locaux uniquement, en cas de tentative de connexion à une machine distante, c’est une demande d’ouverture de session (null) qui  faites sur celle-ci (qui est en général refusée).
 A savoir que ses droits sont restreints volontairement en vue de l’utilisation comme compte de service, ce qui en fait un choix meilleur que LocalSystem. Cependant il cumule les droits de tous les services qui l’utilisent : Si SQL server et IIS s’en servent comme compte de service il aura accès à la fois aux répertoires de SQL Server et à ceux de IIS.

C’est un assez bon compromis en termes de sécurité, même si les droits dont il dispose sont très fonctions de l’utilisation de celui-ci avec d’autres services. Suivant le rôle de votre serveur vous aurez un compte LocalService avec des privilèges plus ou moins élevés, ce qui n’en fait pas un choix parfait.

• Compte NetworkService (nouveauté Windows 2003)

Ce compte est un compte prédéfini (BUILTIN) qui existe sous toutes les versions de Windows à partir de 2003 / XP (2003, XP, Vista et 2008).

Identique au précédent, sauf que les accès réseau sont possibles. Si une tentative de connexion à un autre serveur est faite, ce serveur verra une tentative de connexion du compte de la machine. Exemple : SRVSQL fait une connexion vers SRVWEB, SRVWEB verra une tentative de connexion de \\SRVSQL, qu’il doit autoriser pour qu’elle réussisse.
 Ce type de compte de service permet au serveur de se reconnaître entre eux sans pour autant nécessiter un domaine. Une DMZ est l’endroit idéal où utiliser ce type de compte.

Les limitations restent les même que pour LocalService, les droits de ce type de compte étant fonction de son utilisation pour d’autres services. Il faut considérer qu’il n’a pas d’équivalent, dans le cas de serveurs non connectés à un domaine sont choix peut s’avérer judicieux.

• Compte Utilisateur Local Windows

 Ce compte est à créer manuellement, sa création est possible sous toutes versions de Windows.

Ce compte ne dispose que des privilèges « utilisateur » local. En cas de tentative de connexion à une machine distante, c’est une demande d’ouverture de session (null) qui  faites sur celle-ci (qui est en général refusée).

Les privilèges accordés à ce compte sont uniquement ceux que vous lui accordez (et que l’installation de SQL Server lui accorde). Il faudra lui donner un mot de passe complexe et interdire son expiration si vous souhaitez éviter tout problème.

Ce choix est généralement le meilleur en termes de sécurité pour SQL Server il est équivalent à LocalService, mais ne souffre pas du principal problème de ce dernier : les droits de ce comptes ne sont partagés que par les services où vous l’utilisé, et rien ne vous interdit d’un créer un par service. Cependant si vous avez besoin de réaliser des accès distant à d’autres serveurs ce choix n’est pas intéressant.

C’est le choix parfait pour le service SQL Server (moteur relationel), celui-ci n’ayant pas besoin de se connecter à d’autres machines.

• Compte Utilisateur du Domaine Windows

 Ce compte est à créer manuellement, sa création est possible sous toutes versions de Windows à condition que votre serveur soit joint à un domaine.

Ce compte ne dispose que des privilèges « utilisateur » sur le domaine. En cas de tentative de connexion à une machine distante, c’est le compte de service qui réalise cette connexion, à vous de donner les privilèges nécessaire à cette connexion sur la machine distante (exemple : accordez les droits en écriture sur le partage \\SRVFILES\SAV à DOMAINE\compte_sql_server pour permettre la sauvegarde à distance sur ce partage).

Les privilèges accordés à ce compte sont uniquement ceux que vous lui accordez (et que l’installation de SQL Server lui accorde). Il faudra lui donner un mot de passe complexe et interdire son expiration si vous souhaitez éviter tout problème.

Option la plus courante lorsque vous êtes relié à un domaine, permet plus de facilité au niveau de la gestion des droits entre les serveurs. Nécessite pas contre que SQL Server soit joint à un domaine pour en profiter totalement.

C’est un très bon choix pour l’Agent SQL, ce service ayant très souvent besoin de se connecter à d’autres postes au d’autres serveurs de base de données.

Quels choix faire ?
 Une petite synthèse des options intéressantes par situation.
 Machine autonome sur le réseau :

• Compte Utilisateur local Windows
• Compte LocalService

 Machine sur DMZ nécessitant la connexion à d’autres serveurs

• Compte NetworkService

 Machine sur domaine nécessitant la connexion à d’autres serveurs

• Compte Utilisateur du Domaine

 Bon choix…

sorting listitems in dropdown ASP.NET

ListItemCollection items = new ListItemCollection();
        items.Add( new ListItem("Item 2", "Item 2"));
        items.Add(new ListItem("Item 1", "Item 2"));
        items.Add(new ListItem("Item 3", "Item 2"));
        SortListItems(items, false);  

// true or false based on descending or ascending
        ddlworkshops.DataSource = items ;
        ddlworkshops.DataBind(); 

   public void SortListItems(ListItemCollection items, bool Descending)
    {
        List<ListItem> list = new List();
        foreach (ListItem i in items)
        { list.Add(i);
        }
        if (Descending)
        {   list.Sort(delegate(ListItem x, ListItem y) {  

            return y.Text.CompareTo(x.Text); });
        }
        else
        {   list.Sort(delegate(ListItem x, ListItem y) { 

            return x.Text.CompareTo(y.Text); });
        }
        items.Clear();
        items.AddRange(list.ToArray());
    }

“The remote certificate is invalid according to the validation procedure.” using Gmail SMTP server

Lors de l'envoi d'un mail avec C# Je suis tombé sur l'erreur suivante :


“The remote certificate is invalid according to the validation procedure.” using Gmail SMTP server

j'ai trouvé la solution sur internet

et plus précisemment:

As a workaround, you can switch off certificate validation
put this code somewere before smtpclient.Send():

ServicePointManager.ServerCertificateValidationCallback 

 = delegate(object s, X509Certificate certificate, X509Chain chain, 

 SslPolicyErrors sslPolicyErrors) {  

return true; };

 

Error : The file you are attempting to save or retrieve has been blocked from this Web site by the server administrators.

Error : The file you are attempting to save or retrieve has been blocked from this Web site by the server administrators.
Answer :
1. Start Central Administration.
2. Click Security, and then click "Define Blocked file types"
3. On the Blocked File Types page, click the Web application that you want to configure in the Web Application box.
4. Remove the file name extension from the list of blocked file types.
5. Click OK.

Sharepoint 2010 : Comment créer une liste externe vers SQL Server avec Sharepoint Designer

Sharepoint 2010 inclut une fonctionnalité qui s’appelle le « Business Connectivity Services » (BCS) qui permet à Sharepoint de se connecter à des sources de données externes. Cette fonctionnalité est d’ailleurs incluse dans la version gratuite Sharepoint Foundation.  À l’intérieur de cet article, nous allons regarder comment créer simplement une liste externe qui exploite les données d’une banque de données SQL. Comme toujours dans Sharepoint, il est possible de faire cela de plusieurs manières, mais afin de demeurer le plus simple possible, nous utiliserons Sharepoint Designer 2010.
Pour le bien de l’exemple, nous utiliserons la vue « NTEventLog » de la banque de données « WSS_Logging ». Cette banque contient les événements du journal des événements de Windows.
1-     Ouvrir un site Sharepoint dans Sharepoint Designer.
2-     Dans le panneau de navigation de gauche, sélectionner « Types de contenu externe »

3-     Cliquer le bouton du ruban « Type de contenu externe »


4-     Changer le nom et le nom complet et cliquer sur le lien « Cliquez ici pour découvrir les sources de données externes et définir les opérations »


5-     Cliquer sur le bouton « Ajouter une connexion »


6-     Sélectionner « SQL Server » dans la liste « Type de source de données »


7-     Entrer le nom du serveur et le nom de la banque de données SQL

Lorsque la source de données sera configurée, vous verrez apparaître votre banque de donnée dans l’onglet « Explorateur de source de données ».

8-     Naviguer jusqu’à la table ou la vue que vous désirez exploiter. Utiliser le bouton droit de la souris pour faire apparaître le menu contextuel. À partir de cet endroit, vous devez sélectionner quelles opérations seront disponible. Toujours dans l’idée de rester le plus simple possible, nous allons choisir « Créer toutes les opérations ».

9-     Sharepoint va prendre quelques temps pour créer l’opération et par la suite, l’écran « Propriétés de l’opération » apparaît. Cliquer sur « Suivant ».

10-     À cet endroit, vous devez spécifiez un identificateur. Pour le bien de l’exemple, nous sélectionnerons « RowId ». Par la suite cliquer sur « Terminer » pour compléter après quelques secondes Sharepoint aura terminé la création des opérations.


11-     Par la suite, il ne vous reste qu’à sauvegarder votre source de données en cliquant sur l’icône de la disquette dans le coin supérieur gauche.

12-     Maintenant, dans le panneau de navigation de gauche sélectionner « Listes et bibliothèques » puis cliquer sur le bouton « Liste externe » dans le ruban.


13-     Sélectionner le type de contenu externe et cliquer sur « OK »

14-     Entrer le nom et la description de la liste

15-     Voilà, la liste est maintenant disponible.

16-     Cliquer sur le nom de la liste et par la suite sur le bouton du ruban « Aperçu dans le navigateur » pour voir la liste tel que présentée ci-dessous :
Voilà, c’est tout et c’est aussi simple que cela.

Using DataPager in ListView

If the DataSource is not known statically at design time, the DataPager may not work correctly. The following error could be expected to happen when you click on the link provided by DataPager at the second time:

Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request.

This problem occurs because the DataPager has no idea how to perform or calculate paging for you without knowing what page is supposed to display (i.e., StartIndex, and MaximuumRows in the page) when the DataSource is only known at runtime. Thus, you need to provide this missing piece of information to the DataPager before databinding.

Under Google search, you may find that quite a few people implemented the PreRender event of DataPager to perform databinding. Unfortunately, it doesn't work for this scenario. You can bind the data at DataPager's PreRender event but you are unable to supply paging properties to DataPager as mentioned above. Both StartRowIndex and MaximumRows properties are needed to set for paging before databinding. This problem took me a few hours to resolve. It turns out that the solution is very simple.

The Solution: You should add and implement the PagePropertiesChanging event of ListView. The PagePropertiesChangingEventArgs from the event argument will provide all your needy paging properties (StartRowIndex and MaximumRows) so that you can supply them to the DataPager.

protected void ListView1_PagePropertiesChanging(object sender, PagePropertiesChangingEventArgs e) { this.DataPage1.SetPageProperties(e.StartRowIndex, e.MaximumRows, false); BindData();

 // set DataSource to ListView and call DataBind() of ListView
 }

 If the DataPager is placed inside the ListView, do this: 

protected void ListView1_PagePropertiesChanging(object sender, 

PagePropertiesChangingEventArgs e) {
      ListView lv = sender as ListView;
      DataPager pager = lv.FindControl("DataPage1") as DataPager;
      pager.SetPageProperties(e.StartRowIndex, e.MaximumRows, false);
      BindData(); 

// set DataSource to ListView and call DataBind() of ListView
    } 

SharePoint DateTime Control Validation

Ce code contrôle que la date est obligatoire et valide

                

 <asp:RequiredFieldValidator ID="RequiredFieldValidator18" runat="server" ErrorMessage="La date ouverture des plis est obligatoire."  Text="*"              ControlToValidate="dateOuverturePlisDateTimeControl$dateOuverturePlisDateTimeControlDate" ValidationGroup="group1" Display="Dynamic" ForeColor="Red" ></asp:RequiredFieldValidator>
            
<asp:CompareValidator ID="valDate" runat="server" ForeColor="Red" ControlToValidate="dateOuverturePlisDateTimeControl$dateOuverturePlisDateTimeControlDate"
                 Type="Date" Operator="DataTypeCheck" ErrorMessage="Entrez une date valide" Display="Dynamic"  ValidationGroup="group1" /> 

  <SharePoint:DateTimeControl ID="dateOuverturePlisDateTimeControl"  runat="server" Calendar="GregorianMEFrench"  />