license manager e rdp web access

ansible/003-playbook.md

@@ -111,7 +111,7 @@ Un semplice esempio di condizione `when`:
 
   tasks:
     - name: install postgres
-      yum:
+      apt:
         name: postgresql
         state: latest
       when: ansible_distribution == 'Ubuntu'
@@ -127,7 +127,7 @@ Un esempio di `registered variables`:
 
   tasks:
     - name: Install the httpd package
-      yum:
+      apt:
         name: httpd
         state: present
       register: httpd_installation
@@ -139,7 +139,7 @@ Un esempio di `registered variables`:
       when: httpd_installation.changed == true
 ```
 
-Questo task utilizza il modulo yum per installare il pacchetto httpd. Durante l'esecuzione, il risultato dell'installazione viene registrato nella variabile `httpd_installation`. Avvia infine il servizio httpd, ma solo se l'installazione del pacchetto è stata completata con successo.
+Questo task utilizza il modulo apt per installare il pacchetto httpd. Durante l'esecuzione, il risultato dell'installazione viene registrato nella variabile `httpd_installation`. Avvia infine il servizio httpd, ma solo se l'installazione del pacchetto è stata completata con successo.
 
 ## Loops
 
@@ -264,7 +264,7 @@ Gli `handler` in Ansible consentono l'esecuzione condizionale di specifiche oper
 
   tasks:
     - name: install httpd
-      yum:
+      apt:
         name: httpd
         state: present
       notify:
@@ -280,3 +280,126 @@ Gli `handler` in Ansible consentono l'esecuzione condizionale di specifiche oper
 La parola chiave `notify` serve a richiamare l’handler specificato. Durante la prima esecuzione, una volta installato il software httpd, l’handler verrà attivato e avvierà il servizio. Nelle esecuzioni successive, qualora il pacchetto sia già presente e non subisca modifiche, il task non verrà eseguito e, di conseguenza, neppure l’handler associato verrà richiamato.
 
 Per impostazione predefinita, gli handlers vengono eseguiti solo dopo che tutti i task del playbook sono stati completati. Questo significa che, anche se più task notificano lo stesso handler, quest’ultimo verrà eseguito una sola volta.
+
+## Tags
+
+I tag consentono di contrassegnare specifici task, offrendo la possibilità di selezionare quali parti eseguire di un playbook.
+
+Per aggiungere un tag a un task, è sufficiente utilizzare la direttiva `tags` seguita da un elenco di etichette. Ogni task può essere associato a uno o più tag, come illustrato nell’esempio seguente:
+
+```yaml
+---
+- name: playbook with tags
+  hosts: db
+  become: true
+
+  tasks:
+    - name: install httpd
+      apt:
+        name: httpd
+        state: present
+      tags:
+        - http
+        
+    - name: install postgres
+      apt:
+        name: postgresql
+        state: present
+      tags:
+        - db
+```
+
+In questo esempio, ogni task è associato a un tag specifico, rispettivamente http e db.  In questo modo, è possibile eseguire solo i task contrassegnati da un determinato tag.
+
+### Tag speciali
+
+Ansible offre due tag speciali, `always` e `never`: un task contrassegnato con il tag *always* verrà sempre eseguito, indipendentemente dai tag specificati nella riga di comando. Al contrario, un task contrassegnato con il tag *never* non verrà mai eseguito, a meno che non venga esplicitamente richiesto tramite l’opzione `--tags`.
+
+### Esecuzione tramite riga di comando
+
+Utilizzando l'opzione `--tags`, è possibile specificare i task da eseguire:
+
+```bash
+ansible-playbook playbook.yml --tags "http"
+```
+
+Questo comando eseguirà solo i task contrassegnati con il tag http.
+
+Al contrario, per escludere task specifici dall'esecuzione, si utilizza l'opzione `--skip-tags`:
+
+```bash
+ansible-playbook playbook.yml --skip-tags "db"
+```
+
+Questo comando salterà l'esecuzione di tutti i task contrassegnati con il tag db.
+
+## Variabili
+
+Le variabili sono utilizzate per memorizzare valori, seguendo la sintassi `key: value`.
+
+Per fare riferimento a una variabile in Ansible, si utilizza la sintassi `Jinja2`, racchiudendo il nome della variabile tra le parentesi graffe doppie `{{ }}`. Ad esempio, se si definisce una variabile come `config_path: /opt/my_app/config`, il riferimento a questa variabile sarà `{{ config_path }}`.
+
+Le variabili possono essere utilizzate in diversi contesti:
+
+- Inventory
+- Playbook: variabili definite direttamente nel playbook utilizzando la parola chiave `vars`
+- Command line: variabili passate tramite la riga di comando utilizzando l'opzione `--extra-vars`
+- File esterni: variabili definite in file esterni, richiamabili nel playbook con la parola chiave `vars_file`
+
+```yaml
+---
+- name: Example playbook with variables
+  hosts: webservers
+  vars:
+    app_name: my_app
+    config_file_path: /etc/{{ app_name }}/config.yml
+
+  tasks:
+    - name: Copy the configuration file
+      copy:
+        src: files/config.yml
+        dest: "{{ config_file_path }}"
+        owner: root
+        group: root
+        mode: '0644'
+```
+
+### Registrazione del valore di una variabile
+
+È possibile registrare il risultato di un task all’interno di una variabile, in modo da riutilizzarlo nei task successivi. Per fare ciò, si utilizza la parola chiave `register` all’interno del task:
+
+```yaml
+---
+- name: playbook with variables
+  hosts: db
+
+  tasks:
+    - name: get uptime
+      shell: uptime
+      register: uptime
+
+    - debug:
+        var: uptime.stdout
+```
+
+In questo esempio, il task *get uptime* esegue il comando uptime e registra il risultato nella variabile *uptime*. Successivamente, il valore di *uptime.stdout* viene visualizzato utilizzando il modulo debug.
+
+## Vault
+
+`Ansible Vault` consente di proteggere le informazioni sensibili utilizzate durante l’esecuzione di playbook, come indirizzi, password, chiavi di accesso e altri dati riservati. Qualsiasi dato che non si desidera lasciare in chiaro può essere protetto tramite i vault.
+
+La crittografia delle informazioni può avvenire principalmente in due modi:
+
+- **A livello di file**: Ansible consente di criptare un intero file utilizzando il comando `ansible-vault create example.yml`. Per modificare il file, è necessario utilizzare il comando `ansible-vault edit example.yml`, mentre per leggerne il contenuto, si può utilizzare il comando `ansible-vault view example.yml`
+- **A livello di variabile**: con il comando `ansible-vault encrypt_string 'example' --name 'the secret'` é possibile criptare solo una variabile che sarà successivamente inserita in un playbook o in altre configurazioni
+
+### Algoritmo di crittografia
+
+L’unico algoritmo di crittografia supportato da Ansible Vault è `AES256`.
+
+### Esecuzione del playbook
+
+Durante l'esecuzione del playbook, è necessario immettere la password per consentire ad Ansible di decifrare il contenuto criptato. Questo può essere fatto in due modi:
+
+- Utilizzare il comando `--ask-vault-pass`, che richiede all'utente di digitare la password direttamente nella console
+- Specificare il path di file contenente la password tramite l'opzione `--vault-password-file`

ansible/004-cli.md

@@ -0,0 +1,27 @@
+# Comandi ad hoc in Ansible
+
+Ansible consente l'esecuzione di comandi ad hoc tramite la riga di comando. Questi comandi sono impiegati principalmente per operazioni occasionali e non ripetitive, a differenza dei playbook.
+
+## Sintassi di base
+
+La sintassi generale di un comando ad hoc è la seguente:
+
+```bash
+ansible [pattern] -m [module] -a "[module options]"
+```
+
+Il *pattern* identifica i nodi target su cui eseguire il comando, mentre il modulo specificato determina il tipo di operazione da effettuare.
+
+Alcuni dei moduli più comunemente utilizzati includono `ping`, `setup`, `copy`, `shell`, `service`, e altri. Per eseguire un'operazione di *privilege escalation*, è necessario aggiungere l'opzione `-become`.
+
+Se non viene specificato alcun modulo, Ansible utilizza di default il modulo `command`. Questo modulo è simile al modulo shell, ma presenta alcune limitazioni: non consente l'uso del redirect o del piping.
+
+## Esempi di utilizzo
+
+```bash
+ansible db -m shell -a "uptime"
+
+ansible all -m user -a "name=testuser" --become
+
+ansible all -m copy -a "src=/path/to/file dest=/path/to/file"
+```

ansible/005-roles.md

@@ -0,0 +1,42 @@
+# Roles
+
+I playbook possono diventare complessi quando sono responsabili della configurazione di numerosi sistemi diversi, ciascuno con più attività da gestire. Per affrontare questa complessità, Ansible offre la possibilità di organizzare le attività in una struttura di directory denominata `roles`.
+
+In questa configurazione, i playbook richiamano i ruoli anziché i singoli task. Questo approccio consente di raggruppare le attività in unità logiche, facilitando il riutilizzo dei ruoli in altri playbook.
+
+```yaml
+---
+# Tools for terminal
+- name: TERMINAL - Kitty, Tmux, Fish
+  ansible.builtin.apt:
+    pkg:
+      - kitty
+      - tmux
+      - fish
+    state: present
+```
+
+## Inclusione di un ruolo in un playbook
+
+Per utilizzare un ruolo all’interno di un playbook, è necessario richiamarlo tramite la keyword `roles`, seguita dall’elenco dei ruoli da eseguire:
+
+```yaml
+- hosts: server
+  roles:
+    - test-role
+```
+
+## Struttura
+
+Il comando per la creazione di un ruolo è `ansible-galaxy init test-role`. Questo comando non solo consente di inizializzare un nuovo ruolo, ma offre anche la possibilità di cercare e installare ruoli definiti da altri utenti disponibili online.
+
+Al termine dell’esecuzione del comando, viene generata una directory denominata come il ruolo stesso, con la seguente struttura:
+
+- `Tasks`: la directory Tasks contiene l'elenco dei task eseguiti dal ruolo, specificati nel file `main.yml`
+- `Handlers`: raccoglie gli handlers che possono essere utilizzati all'interno di questo ruolo. Si tratta di task speciali che vengono eseguiti solo quando sono stati notificati da altri task
+- `Defaults`: include le variabili predefinite utilizzate all’interno del ruolo
+- `Vars`: contiene ulteriori variabili
+- `Files`: memorizza i file che devono essere distribuiti sui vari host nel corso dell’esecuzione del ruolo
+- `Meta`: conserva i metadati relativi al ruolo
+
+![ansible-role](asset/img/ansible-role.png)

ansible/006-ansible-galaxy.md

@@ -0,0 +1,21 @@
+# Ansible galaxy
+
+Ansible Galaxy è un `repository` di Ansible che contiene ruoli creati dalla community. È possibile cercare ruoli tramite comandi specifici o attraverso il portale web [https://galaxy.ansible.com/](https://galaxy.ansible.com/). Gli utenti possono da riga di comando installare ruoli e utilizzarli nei playbook.
+
+## Installazione
+
+Per installare un ruolo, utilizzare il seguente comando:
+
+```bash
+ansible-galaxy install username.rolename
+```
+
+Il ruolo verrà scaricato nella directory `~/.ansible/roles/username.rolename`.
+
+### Comandi Utili
+
+Di seguito sono elencati alcuni comandi utili:
+
+- `ansible-galaxy list`: visualizza la lista dei ruoli installati
+- `ansible-galaxy remove [rolename]`: rimuove un ruolo specifico
+- `ansible-galaxy init`: crea un nuovo ruolo

ansible/007-winrm.md

@@ -0,0 +1,33 @@
+# WinRM
+
+Il protocollo W`indows Remote Management` (`WinRM`) è impiegato da Ansible per la comunicazione con host Windows, a differenza delle macchine Unix, dove il collegamento avviene tramite SSH.
+
+## Requisiti
+
+Per configurare correttamente WinRM, è necessario soddisfare i seguenti requisiti:
+
+- Installare il pacchetto `pywinrm` sul node-manager Ansible, tramite il comando `pip install pywinrm`
+- Windows 7, Windows Server 2008 o versioni successive sui nodi da gestire
+- PowerShell 3.0 e .NET 4.0 o versioni successive
+- Per configurare WinRM, bisogna eseguire sui nodi lo script ufficiale di Ansible [`ConfigureRemotingForAnsible.ps1`](https://github.com/ansible/ansible-documentation/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1). Questo crea due listener, uno per il protocollo HTTP e uno per il protocollo HTTPS, sulla macchina Windows. Genera inoltre un certificato autofirmato e implementata un sistema di autenticazione di tipo BASIC, che richiede un nome utente e una password
+
+## Configurazione del playbook
+
+Nel playbook, è necessario specificare le seguenti variabili:
+
+- `ansible_user`
+- `ansible_password`
+- `ansible_connection`: deve essere impostato sul protocollo WinRM
+- `ansible_winrm_server_cert_validation`: da essere impostare su *ignore* per evitare comunicazioni tramite HTTPS con i nodi. Poiché lo script genera un certificato autofirmato, questo non sarà riconosciuto come valido
+
+```yaml
+---
+- name: example winrm
+  hosts: winhost
+  tasks:
+    - name: install Firefox
+      win_chocolatey:
+        name: firefox
+        state: latest
+        force: yes
+```

ansible/ConfigureRemotingForAnsible.ps1

@@ -0,0 +1,435 @@
+#Requires -Version 3.0
+
+# Configure a Windows host for remote management with Ansible
+# -----------------------------------------------------------
+#
+# This script checks the current WinRM (PS Remoting) configuration and makes
+# the necessary changes to allow Ansible to connect, authenticate and
+# execute PowerShell commands.
+#
+# IMPORTANT: This script uses self-signed certificates and authentication mechanisms
+# that are intended for development environments and evaluation purposes only.
+# Production environments and deployments that are exposed on the network should
+# use CA-signed certificates and secure authentication mechanisms such as Kerberos.
+#
+# To run this script in Powershell:
+#
+# [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
+# $url = "https://raw.githubusercontent.com/ansible/ansible-documentation/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
+# $file = "$env:temp\ConfigureRemotingForAnsible.ps1"
+#
+# (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
+#
+# powershell.exe -ExecutionPolicy ByPass -File $file
+#
+# All events are logged to the Windows EventLog, useful for unattended runs.
+#
+# Use option -Verbose in order to see the verbose output messages.
+#
+# Use option -CertValidityDays to specify how long this certificate is valid
+# starting from today. So you would specify -CertValidityDays 3650 to get
+# a 10-year valid certificate.
+#
+# Use option -ForceNewSSLCert if the system has been SysPreped and a new
+# SSL Certificate must be forced on the WinRM Listener when re-running this
+# script. This is necessary when a new SID and CN name is created.
+#
+# Use option -EnableCredSSP to enable CredSSP as an authentication option.
+#
+# Use option -DisableBasicAuth to disable basic authentication.
+#
+# Use option -SkipNetworkProfileCheck to skip the network profile check.
+# Without specifying this the script will only run if the device's interfaces
+# are in DOMAIN or PRIVATE zones.  Provide this switch if you want to enable
+# WinRM on a device with an interface in PUBLIC zone.
+#
+# Use option -SubjectName to specify the CN name of the certificate. This
+# defaults to the system's hostname and generally should not be specified.
+
+# Written by Trond Hindenes <trond@hindenes.com>
+# Updated by Chris Church <cchurch@ansible.com>
+# Updated by Michael Crilly <mike@autologic.cm>
+# Updated by Anton Ouzounov <Anton.Ouzounov@careerbuilder.com>
+# Updated by Nicolas Simond <contact@nicolas-simond.com>
+# Updated by Dag Wieërs <dag@wieers.com>
+# Updated by Jordan Borean <jborean93@gmail.com>
+# Updated by Erwan Quélin <erwan.quelin@gmail.com>
+# Updated by David Norman <david@dkn.email>
+#
+# Version 1.0 - 2014-07-06
+# Version 1.1 - 2014-11-11
+# Version 1.2 - 2015-05-15
+# Version 1.3 - 2016-04-04
+# Version 1.4 - 2017-01-05
+# Version 1.5 - 2017-02-09
+# Version 1.6 - 2017-04-18
+# Version 1.7 - 2017-11-23
+# Version 1.8 - 2018-02-23
+# Version 1.9 - 2018-09-21
+
+# Support -Verbose option
+[CmdletBinding()]
+
+Param (
+    [string]$SubjectName = $env:COMPUTERNAME,
+    [int]$CertValidityDays = 1095,
+    [switch]$SkipNetworkProfileCheck,
+    $CreateSelfSignedCert = $true,
+    [switch]$ForceNewSSLCert,
+    [switch]$GlobalHttpFirewallAccess,
+    [switch]$DisableBasicAuth = $false,
+    [switch]$EnableCredSSP
+)
+
+Function Write-ProgressLog {
+    $Message = $args[0]
+    Write-EventLog -LogName Application -Source $EventSource -EntryType Information -EventId 1 -Message $Message
+}
+
+Function Write-VerboseLog {
+    $Message = $args[0]
+    Write-Verbose $Message
+    Write-ProgressLog $Message
+}
+
+Function Write-HostLog {
+    $Message = $args[0]
+    Write-Output $Message
+    Write-ProgressLog $Message
+}
+
+Function New-LegacySelfSignedCert {
+    Param (
+        [string]$SubjectName,
+        [int]$ValidDays = 1095
+    )
+
+    $hostnonFQDN = $env:computerName
+    $hostFQDN = [System.Net.Dns]::GetHostByName(($env:computerName)).Hostname
+    $SignatureAlgorithm = "SHA256"
+
+    $name = New-Object -COM "X509Enrollment.CX500DistinguishedName.1"
+    $name.Encode("CN=$SubjectName", 0)
+
+    $key = New-Object -COM "X509Enrollment.CX509PrivateKey.1"
+    $key.ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider"
+    $key.KeySpec = 1
+    $key.Length = 4096
+    $key.SecurityDescriptor = "D:PAI(A;;0xd01f01ff;;;SY)(A;;0xd01f01ff;;;BA)(A;;0x80120089;;;NS)"
+    $key.MachineContext = 1
+    $key.Create()
+
+    $serverauthoid = New-Object -COM "X509Enrollment.CObjectId.1"
+    $serverauthoid.InitializeFromValue("1.3.6.1.5.5.7.3.1")
+    $ekuoids = New-Object -COM "X509Enrollment.CObjectIds.1"
+    $ekuoids.Add($serverauthoid)
+    $ekuext = New-Object -COM "X509Enrollment.CX509ExtensionEnhancedKeyUsage.1"
+    $ekuext.InitializeEncode($ekuoids)
+
+    $cert = New-Object -COM "X509Enrollment.CX509CertificateRequestCertificate.1"
+    $cert.InitializeFromPrivateKey(2, $key, "")
+    $cert.Subject = $name
+    $cert.Issuer = $cert.Subject
+    $cert.NotBefore = (Get-Date).AddDays(-1)
+    $cert.NotAfter = $cert.NotBefore.AddDays($ValidDays)
+
+    $SigOID = New-Object -ComObject X509Enrollment.CObjectId
+    $SigOID.InitializeFromValue(([Security.Cryptography.Oid]$SignatureAlgorithm).Value)
+
+    [string[]] $AlternativeName += $hostnonFQDN
+    $AlternativeName += $hostFQDN
+    $IAlternativeNames = New-Object -ComObject X509Enrollment.CAlternativeNames
+
+    foreach ($AN in $AlternativeName) {
+        $AltName = New-Object -ComObject X509Enrollment.CAlternativeName
+        $AltName.InitializeFromString(0x3, $AN)
+        $IAlternativeNames.Add($AltName)
+    }
+
+    $SubjectAlternativeName = New-Object -ComObject X509Enrollment.CX509ExtensionAlternativeNames
+    $SubjectAlternativeName.InitializeEncode($IAlternativeNames)
+
+    [String[]]$KeyUsage = ("DigitalSignature", "KeyEncipherment")
+    $KeyUsageObj = New-Object -ComObject X509Enrollment.CX509ExtensionKeyUsage
+    $KeyUsageObj.InitializeEncode([int][Security.Cryptography.X509Certificates.X509KeyUsageFlags]($KeyUsage))
+    $KeyUsageObj.Critical = $true
+
+    $cert.X509Extensions.Add($KeyUsageObj)
+    $cert.X509Extensions.Add($ekuext)
+    $cert.SignatureInformation.HashAlgorithm = $SigOID
+    $CERT.X509Extensions.Add($SubjectAlternativeName)
+    $cert.Encode()
+
+    $enrollment = New-Object -COM "X509Enrollment.CX509Enrollment.1"
+    $enrollment.InitializeFromRequest($cert)
+    $certdata = $enrollment.CreateRequest(0)
+    $enrollment.InstallResponse(2, $certdata, 0, "")
+
+    # extract/return the thumbprint from the generated cert
+    $parsed_cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
+    $parsed_cert.Import([System.Text.Encoding]::UTF8.GetBytes($certdata))
+
+    return $parsed_cert.Thumbprint
+}
+
+Function Enable-GlobalHttpFirewallAccess {
+    Write-Verbose "Forcing global HTTP firewall access"
+    # this is a fairly naive implementation; could be more sophisticated about rule matching/collapsing
+    $fw = New-Object -ComObject HNetCfg.FWPolicy2
+
+    # try to find/enable the default rule first
+    $add_rule = $false
+    $matching_rules = $fw.Rules | Where-Object { $_.Name -eq "Windows Remote Management (HTTP-In)" }
+    $rule = $null
+    If ($matching_rules) {
+        If ($matching_rules -isnot [Array]) {
+            Write-Verbose "Editing existing single HTTP firewall rule"
+            $rule = $matching_rules
+        }
+        Else {
+            # try to find one with the All or Public profile first
+            Write-Verbose "Found multiple existing HTTP firewall rules..."
+            $rule = $matching_rules | ForEach-Object { $_.Profiles -band 4 }[0]
+
+            If (-not $rule -or $rule -is [Array]) {
+                Write-Verbose "Editing an arbitrary single HTTP firewall rule (multiple existed)"
+                # oh well, just pick the first one
+                $rule = $matching_rules[0]
+            }
+        }
+    }
+
+    If (-not $rule) {
+        Write-Verbose "Creating a new HTTP firewall rule"
+        $rule = New-Object -ComObject HNetCfg.FWRule
+        $rule.Name = "Windows Remote Management (HTTP-In)"
+        $rule.Description = "Inbound rule for Windows Remote Management via WS-Management. [TCP 5985]"
+        $add_rule = $true
+    }
+
+    $rule.Profiles = 0x7FFFFFFF
+    $rule.Protocol = 6
+    $rule.LocalPorts = 5985
+    $rule.RemotePorts = "*"
+    $rule.LocalAddresses = "*"
+    $rule.RemoteAddresses = "*"
+    $rule.Enabled = $true
+    $rule.Direction = 1
+    $rule.Action = 1
+    $rule.Grouping = "Windows Remote Management"
+
+    If ($add_rule) {
+        $fw.Rules.Add($rule)
+    }
+
+    Write-Verbose "HTTP firewall rule $($rule.Name) updated"
+}
+
+# Setup error handling.
+Trap {
+    $_
+    Exit 1
+}
+$ErrorActionPreference = "Stop"
+
+# Get the ID and security principal of the current user account
+$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent()
+$myWindowsPrincipal = new-object System.Security.Principal.WindowsPrincipal($myWindowsID)
+
+# Get the security principal for the Administrator role
+$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator
+
+# Check to see if we are currently running "as Administrator"
+if (-Not $myWindowsPrincipal.IsInRole($adminRole)) {
+    Write-Output "ERROR: You need elevated Administrator privileges in order to run this script."
+    Write-Output "       Start Windows PowerShell by using the Run as Administrator option."
+    Exit 2
+}
+
+$EventSource = $MyInvocation.MyCommand.Name
+If (-Not $EventSource) {
+    $EventSource = "Powershell CLI"
+}
+
+If ([System.Diagnostics.EventLog]::Exists('Application') -eq $False -or [System.Diagnostics.EventLog]::SourceExists($EventSource) -eq $False) {
+    New-EventLog -LogName Application -Source $EventSource
+}
+
+# Detect PowerShell version.
+If ($PSVersionTable.PSVersion.Major -lt 3) {
+    Write-ProgressLog "PowerShell version 3 or higher is required."
+    Throw "PowerShell version 3 or higher is required."
+}
+
+# Find and start the WinRM service.
+Write-Verbose "Verifying WinRM service."
+If (!(Get-Service "WinRM")) {
+    Write-ProgressLog "Unable to find the WinRM service."
+    Throw "Unable to find the WinRM service."
+}
+ElseIf ((Get-Service "WinRM").Status -ne "Running") {
+    Write-Verbose "Setting WinRM service to start automatically on boot."
+    Set-Service -Name "WinRM" -StartupType Automatic
+    Write-ProgressLog "Set WinRM service to start automatically on boot."
+    Write-Verbose "Starting WinRM service."
+    Start-Service -Name "WinRM" -ErrorAction Stop
+    Write-ProgressLog "Started WinRM service."
+
+}
+
+# WinRM should be running; check that we have a PS session config.
+If (!(Get-PSSessionConfiguration -Verbose:$false) -or (!(Get-ChildItem WSMan:\localhost\Listener))) {
+    If ($SkipNetworkProfileCheck) {
+        Write-Verbose "Enabling PS Remoting without checking Network profile."
+        Enable-PSRemoting -SkipNetworkProfileCheck -Force -ErrorAction Stop
+        Write-ProgressLog "Enabled PS Remoting without checking Network profile."
+    }
+    Else {
+        Write-Verbose "Enabling PS Remoting."
+        Enable-PSRemoting -Force -ErrorAction Stop
+        Write-ProgressLog "Enabled PS Remoting."
+    }
+}
+Else {
+    Write-Verbose "PS Remoting is already enabled."
+}
+
+# Ensure LocalAccountTokenFilterPolicy is set to 1
+# https://github.com/ansible/ansible/issues/42978
+$token_path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
+$token_prop_name = "LocalAccountTokenFilterPolicy"
+$token_key = Get-Item -Path $token_path
+$token_value = $token_key.GetValue($token_prop_name, $null)
+if ($token_value -ne 1) {
+    Write-Verbose "Setting LocalAccountTOkenFilterPolicy to 1"
+    if ($null -ne $token_value) {
+        Remove-ItemProperty -Path $token_path -Name $token_prop_name
+    }
+    New-ItemProperty -Path $token_path -Name $token_prop_name -Value 1 -PropertyType DWORD > $null
+}
+
+# Make sure there is a SSL listener.
+$listeners = Get-ChildItem WSMan:\localhost\Listener
+If (!($listeners | Where-Object { $_.Keys -like "TRANSPORT=HTTPS" })) {
+    # We cannot use New-SelfSignedCertificate on 2012R2 and earlier
+    $thumbprint = New-LegacySelfSignedCert -SubjectName $SubjectName -ValidDays $CertValidityDays
+    Write-HostLog "Self-signed SSL certificate generated; thumbprint: $thumbprint"
+
+    # Create the hashtables of settings to be used.
+    $valueset = @{
+        Hostname = $SubjectName
+        CertificateThumbprint = $thumbprint
+    }
+
+    $selectorset = @{
+        Transport = "HTTPS"
+        Address = "*"
+    }
+
+    Write-Verbose "Enabling SSL listener."
+    New-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset -ValueSet $valueset
+    Write-ProgressLog "Enabled SSL listener."
+}
+Else {
+    Write-Verbose "SSL listener is already active."
+
+    # Force a new SSL cert on Listener if the $ForceNewSSLCert
+    If ($ForceNewSSLCert) {
+
+        # We cannot use New-SelfSignedCertificate on 2012R2 and earlier
+        $thumbprint = New-LegacySelfSignedCert -SubjectName $SubjectName -ValidDays $CertValidityDays
+        Write-HostLog "Self-signed SSL certificate generated; thumbprint: $thumbprint"
+
+        $valueset = @{
+            CertificateThumbprint = $thumbprint
+            Hostname = $SubjectName
+        }
+
+        # Delete the listener for SSL
+        $selectorset = @{
+            Address = "*"
+            Transport = "HTTPS"
+        }
+        Remove-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset
+
+        # Add new Listener with new SSL cert
+        New-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset -ValueSet $valueset
+    }
+}
+
+# Check for basic authentication.
+$basicAuthSetting = Get-ChildItem WSMan:\localhost\Service\Auth | Where-Object { $_.Name -eq "Basic" }
+
+If ($DisableBasicAuth) {
+    If (($basicAuthSetting.Value) -eq $true) {
+        Write-Verbose "Disabling basic auth support."
+        Set-Item -Path "WSMan:\localhost\Service\Auth\Basic" -Value $false
+        Write-ProgressLog "Disabled basic auth support."
+    }
+    Else {
+        Write-Verbose "Basic auth is already disabled."
+    }
+}
+Else {
+    If (($basicAuthSetting.Value) -eq $false) {
+        Write-Verbose "Enabling basic auth support."
+        Set-Item -Path "WSMan:\localhost\Service\Auth\Basic" -Value $true
+        Write-ProgressLog "Enabled basic auth support."
+    }
+    Else {
+        Write-Verbose "Basic auth is already enabled."
+    }
+}
+
+# If EnableCredSSP if set to true
+If ($EnableCredSSP) {
+    # Check for CredSSP authentication
+    $credsspAuthSetting = Get-ChildItem WSMan:\localhost\Service\Auth | Where-Object { $_.Name -eq "CredSSP" }
+    If (($credsspAuthSetting.Value) -eq $false) {
+        Write-Verbose "Enabling CredSSP auth support."
+        Enable-WSManCredSSP -role server -Force
+        Write-ProgressLog "Enabled CredSSP auth support."
+    }
+}
+
+If ($GlobalHttpFirewallAccess) {
+    Enable-GlobalHttpFirewallAccess
+}
+
+# Configure firewall to allow WinRM HTTPS connections.
+$fwtest1 = netsh advfirewall firewall show rule name="Allow WinRM HTTPS"
+$fwtest2 = netsh advfirewall firewall show rule name="Allow WinRM HTTPS" profile=any
+If ($fwtest1.count -lt 5) {
+    Write-Verbose "Adding firewall rule to allow WinRM HTTPS."
+    netsh advfirewall firewall add rule profile=any name="Allow WinRM HTTPS" dir=in localport=5986 protocol=TCP action=allow
+    Write-ProgressLog "Added firewall rule to allow WinRM HTTPS."
+}
+ElseIf (($fwtest1.count -ge 5) -and ($fwtest2.count -lt 5)) {
+    Write-Verbose "Updating firewall rule to allow WinRM HTTPS for any profile."
+    netsh advfirewall firewall set rule name="Allow WinRM HTTPS" new profile=any
+    Write-ProgressLog "Updated firewall rule to allow WinRM HTTPS for any profile."
+}
+Else {
+    Write-Verbose "Firewall rule already exists to allow WinRM HTTPS."
+}
+
+# Test a remoting connection to localhost, which should work.
+$httpResult = Invoke-Command -ComputerName "localhost" -ScriptBlock { $using:env:COMPUTERNAME } -ErrorVariable httpError -ErrorAction SilentlyContinue
+$httpsOptions = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
+
+$httpsResult = New-PSSession -UseSSL -ComputerName "localhost" -SessionOption $httpsOptions -ErrorVariable httpsError -ErrorAction SilentlyContinue
+
+If ($httpResult -and $httpsResult) {
+    Write-Verbose "HTTP: Enabled | HTTPS: Enabled"
+}
+ElseIf ($httpsResult -and !$httpResult) {
+    Write-Verbose "HTTP: Disabled | HTTPS: Enabled"
+}
+ElseIf ($httpResult -and !$httpsResult) {
+    Write-Verbose "HTTP: Enabled | HTTPS: Disabled"
+}
+Else {
+    Write-ProgressLog "Unable to establish an HTTP or HTTPS remoting session."
+    Throw "Unable to establish an HTTP or HTTPS remoting session."
+}
+Write-VerboseLog "PS Remoting has been successfully configured for Ansible."

lpic/101/009-virtualizzazione.md

@@ -0,0 +1,76 @@
+# Virtualizzazione
+
+La virtualizzazione è una tecnologia che consente a un software, denominato `hypervisor`, di eseguire processi che emulano un sistema informatico completo. Questo software crea e gestisce VM (VM), definite *guest* dell'hypervisor. Le VM sono ambienti isolati in grado di eseguire sistemi operativi e applicazioni come se fossero computer fisici separati.
+
+Esistono due categorie principali di hypervisor:
+
+- `HV di tipo 1` (`bare-metal`) vengono eseguiti direttamente sull'hardware fisico, senza la necessità di un sistema operativo sottostante. Questi hypervisor gestiscono direttamente le risorse hardware, offrendo prestazioni superiori e una maggiore efficienza. Esempi di hypervisor di tipo 1 includono VMware ESXi, Microsoft Hyper-V e Proxmox
+- `HV di tipo 2` (`hosted`): operano su un sistema operativo esistente. Esempi di hypervisor di tipo 2 includono VMware Workstation, VirtualBox. ecc
+
+Tra gli hypervisor più diffusi nel contesto Linux, si possono citare:
+
+- `Xen`, un hypervisor di tipo 1 ampiamente utilizzato in ambienti di cloud computing
+- `KVM` (*Kernel Virtual Machine*), un modulo del kernel Linux che permette la virtualizzazione. KVM può essere considerato sia un hypervisor di tipo 1 che di tipo 2, a seconda della configurazione. Le VM create tramite KVM utilizzano il demone *libvirt* per la loro gestione. `qemu` è il software su cui si basano le VM gestite da KVM, che all'hypervisor gli strumenti necessari per emulare i dispositivi hardware utilizzati dalle VM
+
+## VM
+
+Le VM possono essere classificate in tre categorie principali:
+
+- `completamente virtualizzate`: sono quelle VM in cui il sistema operativo guest non è consapevole di essere un'istanza virtuale in esecuzione. In questo scenario, l'hypervisor emula completamente l'hardware, consentendo al guest di operare come se fosse installato su un computer fisico. Per le CPU x86, è necessario abilitare le estensioni di virtualizzazione, come VT-x per le CPU Intel e AMD-V per le CPU AMD, affinché la virtualizzazione funzioni correttamente
+- `paravirtualizzate`: al contrario, sono progettate in modo tale che il sistema operativo guest sia consapevole della sua esecuzione in un ambiente virtuale. Questi guest utilizzano driver speciali, noti come *guest driver*, per interagire con le risorse hardware e software dell'hypervisor
+- `ibride`: combinano elementi delle due precedenti tipologie. In un ambiente ibrido, alcune parti del sistema operativo guest possono essere paravirtualizzate, mentre altre possono essere completamente virtualizzate
+
+### Immagini disco
+
+I tipi principali di immagini disco utilizzate dalle VM sono:
+
+- `COW` (`copy-on-write`): un metodo che crea un file con un limite di dimensione predefinito. In questo caso, la dimensione dell'immagine sul disco aumenta solo quando i dati vengono effettivamente scritti, senza superare il limite stabilito. Questo approccio consente di risparmiare spazio su disco, poiché inizialmente non viene allocato spazio per i dati che non sono stati ancora scritti. Il formato comunemente utilizzato per le immagini disco COW è `qcow2`
+- `RAW`: sono file che hanno tutto il loro spazio pre-allocato al momento della creazione. Ad esempio, un file di immagine disco RAW da 10 GB occuperà esattamente 10 GB sull'hypervisor, indipendentemente dal fatto che i dati siano stati scritti o meno
+
+### D-BUS Machine ID
+
+Il D-BUS Machine ID è un identificatore univoco assegnato a un sistema Linux al momento della sua creazione.
+
+Per verificare se un D-BUS Machine ID esiste già, è possibile utilizzare il seguente comando:
+
+```bash
+dbus-uuidgen --ensure
+```
+
+Se il comando non restituisce errori, significa che esiste già un ID per il sistema. Per visualizzare l'ID attuale, si può utilizzare il comando:
+
+```bash
+dbus-uuidgen --get
+```
+
+Il D-BUS Machine ID è memorizzato nel file `/var/lib/dbus/machine-id`, che è un collegamento simbolico a `/etc/machine-id`.
+
+#### Generazione di un nuovo ID
+
+Se è necessario generare un nuovoe ID, è possibile farlo seguendo questi passaggi:
+
+```bash
+rm -rf /etc/machine-id
+
+# Generare un nuovo ID
+dbus-uuidgen --ensure=/etc/machine-id
+```
+
+## Container
+
+I container rappresentano una tecnologia di virtualizzazione leggera che differisce dalle VM. La principale distinzione risiede nel fatto che i container condividono lo stesso kernel del sistema operativo host, mentre le VM eseguono un sistema operativo completo e indipendente.
+
+### Differenze con le VM
+
+I container contengono solo le librerie e le dipendenze necessarie per l'esecuzione dell'applicazione, senza includere l'intero sistema operativo. Vengono eseguiti direttamente sull'host, eliminando la necessità di un hypervisor per la gestione delle risorse hardware.
+
+Al contrario, ogni macchina virtuale esegue un sistema operativo completo, comprensivo del proprio kernel, librerie e applicazioni. Ogni VM ha un sistema operativo guest installato, che può differire dal sistema operativo host. Le VM richiedono un hypervisor per gestire l'allocazione delle risorse hardware, il che comporta un sovraccarico maggiore rispetto ai container.
+
+| Caratteristica                | Container                                     | VM                                    |
+|-------------------------------|-----------------------------------------------|---------------------------------------|
+| Kernel                        | Condivide il kernel dell'host                 | Esegue un proprio kernel              |
+| Dimensione                    | Leggeri, solo librerie e dipendenze           | Più pesanti, includono un OS completo |
+| Avvio                         | Rapido, senza hypervisor                      | Più lento, richiede un hypervisor     |
+| Isolamento                    | Minore isolamento, solo a livello di processo | Isolamento completo                   |
+
+![container_vs_vm](asset/image/container_vs_vm.png)

lpic/101/009_virtualizzazione.md

@@ -1,65 +0,0 @@
-# Concetti
-
-La virtualizzazione consente ad un software, denominato *hypervisor*, di eseguire processi che contengono un sistema informatico completamente emulato. 
-
-Si tratta di un software che crea e gestisce macchine virtuali (VM), definite *guest* dell HV. Le macchine virtuali sono ambienti isolati che possono eseguire sistemi operativi e applicazioni come se fossero computer fisici separati.
-
-Esistono due tipi principali di hypervisor:
-
-- **Hypervisor di tipo 1** (*bare-metal*): vengono eseguiti direttamente sull'hardware fisico. Non richiedono un sistema operativo sottostante e gestiscono direttamente le risorse hardware. Esempi di hypervisor di tipo 1 includono VMware ESXi, Microsoft Hyper-V e Xen.
-
-- **Hypervisor di tipo 2** (*hosted*): vengono eseguiti su un sistema operativo esistente. Esempi di hypervisor di tipo 2 includono VMware Workstation, VirtualBox e Parallels Desktop.
-
-Gli hypervisor comunemente usati su Linux sono:
-
-- **Xen**: un hypervisor di **tipo I** o *bare-metal*
-- **KVM**: *Kernel Virtual Machine* e' un modulo del Kernel per la virtualizzazione. E' un hypervisor sia di tipo I che di tipo II. Le VM erogate tramite KVM usano il demone *libvirt* per essere create e gestite. *qemu* e' il software su cui si basano le VM gestite da KVM. Fornisce all'HV il software per emulare i dispositivi HW che la VM utilizza.
-
-## Macchine virtuali
-
-Esistono tre tipi di VM:
-
-- *completamente virtualizzate*: un guest completamente virtualizzato e' quello in cui il guest non e' consapevole di essere un'istanza virtuale in esecuzione. Nelle CPU x86 bisogna abilitare le estensioni VT-X per CPU Intel e AMD-V per CPU AMD.
-  
-- *paravirtualizzate*: un guest completamente paravirtualizzato e' quello in cui il guest e' consapevole di essere un'istanza virtuale in esecuzione. Questi tipi di guest fanno uso di driver speciali (*guest driver*) per utilizzare le risorse hardware e software dell'hypervisor.
-
-- *ibride*: questo approccio combina elementi di virtualizzazione completamente virtualizzata e paravirtualizzata. In un ambiente ibrido, alcune parti del SO guest possono essere paravirtualizzate, mentre altre possono essere completamente virtualizzate 
-
-### Immagini disco
-
-I tipi principali di immagini disco utilizzate dalle VM sono:
-
-- *COW*: *copy-on-write*. E' un metodo che crea un file su disco con un limite di dimensione predefinito. La dimensione dell'immagine sul disco aumenta, ma non oltre il limite prestabilito, solo quando i dati vengono effettivamente scritti sul disco. Il formato usato e' `qcow2`.
-- *RAW*: si tratta di un file che ha tutto il suo spazio pre-allocato. Per esempio, un file di immagine disco raw da 10GB occupa esattamente 10GB sull'HV. 
-
-### D-BUS Machine ID
-
-Si tratta di un numero che identifica univocamente un sistema Linux, che si genera la momento della sua creazione. 
-
-```bash
-dbus-uuidgen --ensure # Se non viene restituito un errore, esiste un ID per il sistema
-
-dbus-uuidgen --get
-e3c4be9c5ad146d4800150b18f31d073
-```
-Il D-BUS Machine ID si trova in `/var/lib/dbus/machine-id`, che e' un collegamento simbolico a `/etc/machine-id`.
-
-Per generare un nuovo ID:
-
-```bash
-rm -rf /etc/machine-id
-
-dbus-uuidgen --ensure=/etc/machine-id
-```
-
-## Container
-
-La principale differenza tra macchine virtuali e container è che questi ultimi condividono lo stesso kernel del sistema operativo host,
-Contengono solo le librerie e le dipendenze necessarie per l'applicazione, senza l'intero sistema operativo.
-I container vengono eseguiti direttamente sull'host, senza la necessità di un hypervisor.
-
-Ogni VM esegue un sistema operativo completo, con il proprio kernel, librerie e applicazioni. Ogni VM ha il proprio sistema operativo guest installato, che può essere diverso dal sistema operativo host.
-Richiedono un hypervisor per gestire l'allocazione delle risorse hardware.
-
-![container_vs_vm](/asset/image/container_vs_vm.png)
-

winserver/001-installazione-ad.md

@@ -0,0 +1,83 @@
+# Windows Server 2025
+
+## First step
+
+- Installazione della `Desktop Experience`
+- Disabilitare l'utente `Administrator` locale creato di default e crearne uno personalizzato
+
+![disable-admin](asset/img/disable-admin.png)
+
+- Disabilitare l'avvio automatico di `Server Manager`
+
+![disable-auto-start-sm](asset/img/disable-auto-start-sm.png)
+
+- Consigliato sempre fare tutti gli update
+
+## Configurazione iniziale
+
+- Impostare un hostname. Aprire `Server Manager`, recarsi nella sezione `Local Server`, quindi `Computer Name`
+
+![set-hostname](asset/img/set-hostname.png)
+
+- Sempre in `Server Manager`, abilitare il `Remote Desktop`
+- Impostare la `timezone` corretta
+- Volendo, é consigliato specificare gli utenti che possono accedere alla macchina tramire `RDP`
+
+![rdp](asset/img/rdp.png)
+
+- Scaricare e installare [Windows Admin Center](https://www.microsoft.com/it-it/evalcenter/download-windows-admin-center)
+
+> `Windows Admin Center` è una piattaforma web di gestione centralizzata per l’amministrazione di server e dispositivi Windows, che consente di monitorare, configurare e gestire diversi aspetti dei sistemi Windows da un’interfaccia centralizzata. Da sottolineare, che non permette di gestire Active Directory, ma solo del server.
+>
+> Una volta avviata l'applicazione, all'indirizzo `https://localhost` si aprirá l'interfaccia di gestione
+
+![win-admin-center](asset/img/win-admin-center.png)
+
+Maggiori informazioni:
+
+- [Install Windows Admin Center](https://github.com/MicrosoftDocs/windowsserverdocs/blob/main/WindowsServerDocs/manage/windows-admin-center/deploy/install.md)
+- [Gestire le macchine Windows con Windows Admin Center](https://www.ictpower.it/sistemi-operativi/gestire-le-macchine-windows-con-windows-admin-center-v2.htm)
+
+## Installazione di Active Directory
+
+> [Installare un domain controller in Windows Server 2025](https://www.ictpower.it/sistemi-operativi/installare-un-domain-controller-in-windows-server-2025.htm)
+
+`Active Directory Domain Services` (`AD DS`) consente la gestione centralizzata di utenti, computer e risorse condivise all'interno di una rete aziendale.
+
+Le sue caratteristiche principali:
+
+- AD DS consente l'impostazione di regole generali tramite le `Group Policy`
+- Offre la possibilità di strutturare logicamente la rete aziendale in modo gerarchico, utilizzando `domini`, `alberi`, `foreste` e `Unità Organizzative` (OU)
+- Integra un `servizio DNS` interno, che consente la gestione automatica della risoluzione dei nomi e degli indirizzi IP dei dispositivi presenti nella rete
+
+L'installazione del ruolo AD DS trasforma il server in un `Domain Controller`, che sará responsabile della gestione delle autenticazioni e delle autorizzazioni, nonché della supervisione delle policy di sicurezza e delle configurazioni di rete.
+
+- Da `Server Manager > Manage > Add Roles and Features`, selezionare e installare la feature `Active Directory Domain Services`
+- Impostare un indirizzo IP statico, avendo cura di configurare il server stesso come server DNS primario
+
+![static-ip](asset/img/static-ip.png)
+
+- Promuovere l'host a `Domain Controller`, creando una nuova foresta
+- Impostare una password di restore
+
+## Aggiunta di un secondo DC
+
+- Creare una nuova macchina Windows Server
+- Impostare IP statico e come server DNS il DC principale
+- Inserire la macchina nel dominio
+- Una volta riavviato, disabilitare l'admin locale
+- Da `Server Manager > Manage > Add Roles and Features`, selezionare e installare la feature `Active Directory Domain Services`
+- Promuovere il nuovo server a domain controller secondario, **aggiungendolo a un dominio esistente**
+
+![add-to-an-existing-domain](asset/img/add-to-an-existing-domain.png)
+
+- Impostare il nuovo DC anche come `Global catalog`
+- Selezionare `Replicate from any domain controller`
+
+![replicate-from-any-dc](asset/img/replicate-from-any-dc.png)
+
+- Al termine del riavvio, verificare che sia stato promosso correttamente a secondo DC
+
+![secondary-dc](asset/img/secondary-dc.png)
+
+- SU entrambi i DC, impostare come server DNS primario l'indirizzo IP del server stesso e come secondario l'indirizzo IP del altro domain controler. Quindi, per esempio, nel caso del DC1, impostare come server DNS primario l'indirizzo IP del DC1 e come secondario l'IP del DC2

winserver/002-domain-join.md

@@ -0,0 +1,45 @@
+# Active Directory Domain Services
+
+## Creazione utente
+
+- Da `Control Panel > All Control Panel Items > Windows Tools` aprire `Active Directory Users and Computers`
+- Oppure, `SUPER + R`, quindi `dsa.msc`
+- Qui si trova l'albero della foresta di AD. Nella directory `Users` si trovano tutti gli utenti
+
+![aduc](asset/img/aduc.png)
+
+- Creare una nuova `Organizational Unit`, che consente di raggruppare logicamente oggetti come account utente, account di servizio o account computer
+- Creare un nuovo utente. L'ideale sarebbe dare all'utente la possibilitá di cambiare password al prossimo login
+- Dal client, fare il join a dominio. Assicurarsi che il DC sia raggiungibile. Rinominare il pc col comando powershell `Rename-Computer -NewName "CORP01" -Restart`.
+
+```cmd
+PS C:\Users\dadoadmin> ipconfig
+
+Ethernet adapter Ethernet:
+
+   Connection-specific DNS Suffix  . :
+   Link-local IPv6 Address . . . . . : fe80::416c:8c3d:318b:bf8b%4
+   IPv4 Address. . . . . . . . . . . : 10.0.2.16
+   Subnet Mask . . . . . . . . . . . : 255.255.255.0
+   Default Gateway . . . . . . . . . : 10.0.2.1
+
+PS C:\Users\dadoadmin> ping 10.0.2.15
+
+Pinging 10.0.2.15 with 32 bytes of data:
+Reply from 10.0.2.15: bytes=32 time<1ms TTL=128
+Reply from 10.0.2.15: bytes=32 time<1ms TTL=128
+Reply from 10.0.2.15: bytes=32 time=1ms TTL=128
+
+PS C:\Users\dadoadmin> ping dc01
+
+Pinging DC01.local [fe80::44d8:6eb0:e4a5:ca72%4] with 32 bytes of data:
+Reply from fe80::44d8:6eb0:e4a5:ca72%4: time<1ms
+Reply from fe80::44d8:6eb0:e4a5:ca72%4: time<1ms
+Reply from fe80::44d8:6eb0:e4a5:ca72%4: time<1ms
+```
+
+- É possibile mettere una macchina a dominio tramite Powershell col comando `add-computer –domainname "YourDomainName"  -restart`
+
+> Entrambi i comandi sopra elencati, devono essere eseguiti coi privilegi di admin
+
+- Ora sará possibile loggarsi con l'utente di dominio

winserver/003-permessi.md

@@ -0,0 +1,66 @@
+# Permessi
+
+La procedura inizia con la creazione, dal DC, di una directory principale (ad esempio `Data`) all’interno della quale vengono definite le sottodirectory necessarie per l’organizzazione delle risorse
+
+## Autenticazione e controllo degli accessi
+
+L’accesso alle risorse condivise è regolato dal protocollo `Kerberos`, che opera secondo due fasi distinte:
+
+- Il protocollo rilascia un ticket di logon al dominio Active Directory (AD) solo in caso di credenziali corrette
+- Al tentativo di accesso a una risorsa specifica, Kerberos verifica le credenziali e, se valide, concede un ticket di accesso che abilita l’utilizzo della risorsa stessa
+
+## Permessi di sharing
+
+Si distinguono due livelli di permessi:
+
+- `sharing permissions`: definiscono chi può accedere alla risorsa tramite rete
+- `security permissions`: stabiliscono le azioni consentite (lettura, scrittura, esecuzione, ecc.) su file e cartelle
+
+È prassi comune assegnare il permesso `Full Control` al gruppo `Everyone` (inteso come tutti gli utenti autenticati nel dominio AD) a livello di sharing: la gestione effettiva degli accessi avviene infatti tramite i `security permissions`, che devono essere configurati in modo da limitare l’accesso solo agli utenti o ai gruppi autorizzati.
+
+![sharing-folder](asset/img/sharing-folder.png)
+
+## Permessi di security
+
+Per consentire a utenti specifici o appartenenti a una determinata Organizational Unit di accedere e modificare i contenuti della directory condivisa, è necessario intervenire sui permessi di sicurezza.
+
+![security-permissions](asset/img/security-permissions.png)
+
+## Gruppi
+
+In `Active Directory Users and Computers` è possibile creare un nuovo gruppo. Prima della creazione, è necessario distinguere tra due tipologie di gruppi:
+
+- `Gruppi di distribuzione`: utilizzati principalmente per la distribuzione di contenuti, ad esempio per l’invio di email a più destinatari
+- `Gruppi di security`: impiegati per gestire i permessi di accesso alle risorse
+
+I gruppi possono avere diversi scope:
+
+- `Global`: generalmente utilizzato per creare utenti che operano esclusivamente all'interno del proprio dominio di competenza
+- `Universal`:  consente la creazione di utenti che possono operare in tutti i domini della foresta
+
+Dopo aver selezionato il tipo e lo scope, è possibile aggiungere i membri corrispondenti tramite l’apposita scheda `Members`
+
+![groups](asset/img/groups.png)
+
+### Assegnazione dei permessi
+
+Una volta creato il gruppo, è possibile consentire l’accesso alle directory precedentemente condivise. Per fare ciò:
+
+- Accedere alla scheda `Security > Advanced` della directory condivisa
+- Disabilitare l’ereditarietà dei permessi dalla cartella superiore, qualora siano presenti sottocartelle a cui devono accedere solo utenti specifici
+- Convertire i permessi ereditati in permessi espliciti
+
+A questo punto, è possibile rimuovere il gruppo predefinito `Users` e aggiungere il gruppo creato in precedenza, in modo da limitare l’accesso alla risorsa solo agli utenti membri del gruppo specifico
+
+![disable-inheritance](asset/img/disable-inheritance.png)
+
+![access-deny](asset/img/access-deny.png)
+
+### Gestione dei permessi per le sottodirectory
+
+Nel caso in cui sia necessario creare una sottodirectory a cui deve accedere solo un utente specifico del gruppo, è possibile:
+
+- Negare esplicitamente l’accesso agli altri utenti
+- Rimuovere il gruppo dalla lista dei permessi
+
+Si ricorda che i permessi di negazione hanno sempre la precedenza su quelli di concessione.

winserver/004-gpo.md

@@ -0,0 +1,80 @@
+# Group Policy Object
+
+Le `Group Policy Object` (`GPO`) rappresentano un insieme di criteri configurabili che possono essere associati a OU, gruppi o altri oggetti all’interno di un dominio Active Directory. Attraverso il `Group Policy Management`, è possibile visualizzare le policy predefinite, come la `Default Domain Policy`, che si applica a tutti gli utenti del dominio, e la `Default Domain Controller Policy`, che è associata ai domain controller del dominio.
+
+Le policy vengono create all'interno della directory `Group Policy Object` e successivamente collegate agli oggetti pertinenti.
+
+![gpm](asset/img/gpm.png)
+
+## Auto mount di una unità
+
+Per configurare l'auto mount delle unità, seguire i passaggi seguenti:
+
+- Creare una GPO denominata `Mapped Drive` e associarla a una Unità Organizzativa
+- Creare la policy necessaria per mappare l'unità disco desiderata, come mostrato di seguito
+
+![gpo](asset/img/gpo.png)
+
+### Proprietà
+
+Nella sezione **General** sono configurati i seguenti parametri:
+
+- **Location**: specifica il percorso della risorsa di rete da mappare, ad esempio `\\dc01\Tecnico`
+- **Reconnect**: selezionando questa opzione, l'unità verrà riconnessa automaticamente ad ogni accesso dell'utente
+- **Label as**: consente di assegnare un nome all'unità mappata
+- **Use**: permette di specificare una lettera di unità
+
+![gpo-targeting](asset/img/gpo-targeting.png)
+
+Nella sezione **Targeting**, è possibile definire le condizioni per l'applicazione della policy. È possibile, ad esempio, configurare la policy affinché solo gli utenti di una specifica OU ricevano la mappatura dell'unità.
+
+Per garantire l'applicazione immediata della policy sul client, eseguire il comando `gpupdate /force`. Questo comando forza l’aggiornamento delle Group Policy sul sistema locale, garantendo l’applicazione immediata delle nuove configurazioni.
+
+## Home folders
+
+Le `home folders` sono le cartelle degli utenti mappate per ciascun utente all'interno di un ambiente di rete.
+
+È necessario creare una parent directory denominata `Users` all’interno del percorso `C:\Data`, precedentemente condiviso. Questa directory fungerà da contenitore per le home folders di tutti gli utenti.
+
+Per garantire l’accesso corretto, bisogna di configurare i seguenti permessi:
+
+- `Share`: impostare il permesso `Everyone` a `Full Control`
+- `Security`: disabilitare l’ereditarietà dei permessi e convertirli in espliciti. Successivamente, rimuovere il gruppo Users dall’elenco dei permessi, in modo che ogni utente possa accedere solo alla propria home folder.
+
+![users-folder](asset/img/users-folder.png)
+
+### Configurazione
+
+Accedere a `dsa.msc`, selezionare gli utenti desiderati, quindi accedere a `Properties > Profile`. Impostare il percorso della home folder `\\dc01\Users\%username%`.
+
+![home-folder](asset/img/home-folder.png)
+
+Questa configurazione consente la creazione automatica di una cartella per ogni utente.
+
+![created-user-folder](asset/img/created-user-folder.png)
+
+La home folder verrà automaticamente mappata come unità di rete sulla lettera selezionata durante la configurazione. Tale cartella risulterà accessibile esclusivamente all’utente proprietario, mentre sarà inaccessibile agli altri utenti e agli amministratori di sistema, a meno di modifiche esplicite ai permessi.
+
+## Printers
+
+Per rendere disponibile una stampante agli utenti di dominio direttamente al login, è necessario eseguire le seguenti operazioni:
+
+- Accedere al server designato e installare il driver della stampante. Dopo l’installazione, la stampante sarà visibile nella sezione `Devices and Printers` del Control Panel
+
+![printer-on-server](asset/img/printer-on-server.png)
+
+- Selezionare la stampante installata e attivare la condivisione. Durante la procedura, assicurarsi di spuntare l’opzione `List in directory`, che consente di rendere la stampante visibile come oggetto all’interno di Active Directory
+
+![printer-sharing](asset/img/printer-sharing.png)
+
+- Tramite *Server Manager*, aggiungere il ruolo `Print and Document Services`. Questo ruolo fornisce gli strumenti necessari per amministrare le stampanti in modo centralizzato
+
+![print-role](asset/img/print-role.png)
+
+- Dopo l’installazione del ruolo, sarà disponibile la console `Print Management`, che funge da dashboard per la gestione delle stampanti
+
+![print-management](asset/img/print-management.png)
+
+- L’ultimo passaggio consiste nel creare una Group Policy che associ le stampanti installate sul print server a utenti o gruppi specifici, ad esempio un’OU. Nella configurazione della policy deve essere inserito il percorso UNC della stampante
+
+![printer-policy](asset/img/printer-policy.png)

winserver/005-profiles.md

@@ -0,0 +1,70 @@
+# Profili
+
+## Profili di roaming
+
+I profili di roaming consentono agli utenti di mantenere le proprie impostazioni, documenti e dati personali durante gli spostamenti tra diverse postazioni di lavoro. A differenza dei profili locali, i profili di roaming sono memorizzati su una risorsa di rete e vengono caricati automaticamente all’accesso dell’utente a qualsiasi postazione.
+
+### Configurazione
+
+Per implementare i profili di roaming, creare una directory dedicata sul DC:
+
+- Creare la cartella `C:\Roaming` sul server
+- Accedere a `Server Manager > File and Storage Services > Shares`
+- Dal menu `Task`, selezionare `New Share` e scegliere `SMB Share - Quick`
+
+![smb-share](asset/img/smb-share.png)
+
+- Impostare `C:\Roaming` come percorso personalizzato per i profili di roaming
+- Assegnare alla condivisione il nome `roaming$` per renderla nascosta agli utenti standard
+- Abilitare l'opzione `Enable access-based enumeration`, che consente a ciascun utente di accedere solo ai file e alle cartelle di cui è proprietario
+- È fondamentale **personalizzare i permessi**, iniziando a `disabilitare l'eredità`
+- Rimuovere il gruppo *Users* e aggiungere il gruppo o l'utente specifico, ad esempio *Commerciale*
+- Applicare i permessi solo a questa directory e non alle sottocartelle, selezionando `This folder only`. Nelle impostazioni avanzate dei permessi, abilitare solo le opzioni `List folder / Read data` e `Create folders`
+
+![share-permission](asset/img/share-permission.png)
+
+### Associare il profilo di roaming agli utenti
+
+- Aprire `dsa.msc`
+- Selezionare gli utenti o il gruppo di interesse, compatibilmente coi permessi assegnati alla share
+- Nel campo `Profile path`, impostare il percorso `\\DC01\roaming$\%username%`
+
+In questo modo, il profilo verrà caricato automaticamente via rete al momento dell’accesso.
+
+![profile-path](asset/img/profile-path.png)
+
+> Affiché i profili di roaming funzionino correttamente, è necessario che tutti i sistemi operativi delle postazioni di lavoro siano dello stesso tipo.
+
+![roaming-profile](asset/img/roaming-profile.png)
+
+## Profili mandatory
+
+I profili mandatory sono profili utente che non consentono modifiche al profilo stesso. Questa impostazione è progettata per garantire che gli utenti non possano alterare il proprio ambiente di lavoro, evitando problematiche legate all'uso improprio del computer, come la cancellazione errata di documenti.
+
+### Implementazione
+
+- Creare la cartella `C:\Mandatory` sul DC
+- Condividere la cartella concedendo il permesso `Full Control` al gruppo `Everyone`
+- Le directory degli utenti saranno accessibili tramite il percorso UNC ([Universal Naming Convention - Wikipedia](https://it.wikipedia.org/wiki/Universal_Naming_Convention)) `\\dc01\Mandatory`
+- Creare una OU denominata *Mandatory*
+- Creare un utente dedicato all'interno di questa OU
+- Selezionare l'utente e, in `Properties`, impostare il `Profile Path` `\\dc01\Mandatory\%username%`
+
+#### Impostazione dei Permessi
+
+- Selezionare `Properties` della directory `\\dc01\Mandatory\user.V6`
+- In `Security > Advanced`, diventare i proprietari della directory, selezionando l'opzione `Replace owner on subcontainers and objects`
+
+![mandatory-profile](asset/img/mandatory-profile.png)
+
+- Nella sezione `Permissions`, spuntare `Replace all child object permissions`
+
+![permission-mandatory](asset/img/permission-mandatory.png)
+
+#### Modifica del File NTUSER.DAT
+
+- Ora è possibile accedere alla directory e visualizzarne il contenuto
+- Individuare il file `NTUSER.DAT`, rinominandolo in `NTUSER.man`. Questa operazione trasforma il profilo in un profilo mandatory
+- Infine, riassegnare la ownership della cartella del profilo all’utente corrispondente, verificando che i permessi siano configurati correttamente
+
+Dopo queste operazioni, l’utente potrà creare, modificare o eliminare file durante la sessione di lavoro. Al riavvio del sistema, tutte le modifiche apportate verranno annullate e il profilo tornerà allo stato originale.

winserver/006-deduplica.md

@@ -0,0 +1,30 @@
+# Depluplica dei file
+
+Windows Server include una funzione di deduplicazione (`Data Deduplication`) progettata per ridurre la ridondanza dei file memorizzati. Questa funzionalità, una volta attivata, identifica i file duplicati all’interno di un volume, mantiene una sola copia fisica di ciascun file e sostituisce le copie duplicate con collegamenti alla copia originale.
+
+## Attivazione
+
+Per abilitare la deduplicazione dei dati, è necessario aggiungere il ruolo corrispondente tramite Server Manager:
+
+- Selezionare `Manage > Add Roles and Features`
+- Nella sezione `Server Roles`, individuare e selezionare `Data Deduplication`
+- Completare la procedura di installazione seguendo le istruzioni visualizzate
+
+![data-deduplication](asset/img/data-deduplication.png)
+
+Al termine dell’installazione, la funzionalità sarà disponibile all’interno di `File and Storage Services` in Server Manager.
+
+> La deduplicazione non può essere applicata al volume di boot (solitamente C:). È necessario disporre di un volume dati dedicato su cui attivare la funzionalità.
+
+![c-data-deduplication](asset/img/c-data-deduplication.png)
+
+## Configurazione
+
+Durante la configurazione, sono disponibili diverse opzioni:
+
+- Disattivato: la funzionalità non è operativa
+- `General purpose file server`: modalità consigliata per la maggior parte degli scenari, ottimizzata per file server generici
+
+È possibile escludere specifiche estensioni di file e programmare le operazioni di deduplicazione secondo necessità.
+
+![deduplication-option](asset/img/deduplication-option.png)

winserver/007-ruoli-fsmo.md

@@ -0,0 +1,21 @@
+# Ruoli FSMO
+
+Active Directory è costituito da un insieme di ruoli e funzionalità distribuiti tra i DC della struttura. Il primo domain controller installato assume automaticamente anche il ruolo di `Global Catalog`. Tale ruolo consente al DC di contenere una copia completa di tutti gli oggetti dell’intera foresta, garantendo così la possibilità di rispondere a richieste relative a utenti, domini e altri oggetti di Active Directory senza dover interpellare altri server.
+
+All’interno di Active Directory, sono definiti cinque ruoli principali, noti come `FSMO` (`Flexible Single Master Operations`). Questi ruoli dovrebbero essere distribuiti tra più domain controller. Tuttavia, nelle strutture di dimensioni ridotte, dove è presente un solo DC, tutti i ruoli FSMO risiedono su tale macchina. I ruoli FSMO possono essere trasferiti o ripresi, anche nel caso in cui il controller che li detiene non sia più operativo.
+
+## Elenco dei ruoli FSMO
+
+- `Schema master`: gestisce le modifiche allo schema di Active Directory. In una foresta è presente un solo schema master
+- `Domain naming master`: consente di aggiungere o rimuovere domini all’interno di una foresta
+- `Infrastructure master`: i occupa dell’aggiornamento dei *Security Identifier* (SID) e dei nomi dei domini. Questo ruolo non può essere installato su un server che funge anche da Global Catalog
+- `PDC emulator`: mantiene la compatibilità con macchine basate su Windows NT 4.0, emulando il comportamento del `Primary Domain Controller` (PDC) che esisteva nelle versioni precedenti di Windows. In passato, esisteva un solo PDC e tutti gli altri erano `Backup Domain Controller` (BDC). Oggi, tutti i domain controller operano allo stesso livello, ma il ruolo PDC emulator rimane per garantire la retrocompatibilità
+- `RID master`: uno dei ruoli più critici, in quanto gestisce l’assegnazione dei *Relative Identifier* (RID) ai domain controller. I RID sono identificatori univoci utilizzati per creare nuovi oggetti all’interno del dominio. Ogni DC riceve un pool di RID dal RID master. Quando il pool si esaurisce, il RID master ne fornisce uno nuovo. In una foresta può esistere un solo RID master
+
+### Verifica dei ruoli FSMO
+
+Per visualizzare l’elenco dei ruoli FSMO assegnati ai domain controller, è possibile utilizzare il seguente comando:
+
+```cmd
+netdom query fsmo
+```

winserver/008-dns.md

@@ -0,0 +1,15 @@
+# DNS
+
+Il `Domain Name System` (`DNS`) è un componente fondamentale per la risoluzione dei nomi di dominio in indirizzi IP. All'interno del `DNS Manager`, è possibile gestire diverse proprietà della zona e configurare i parametri necessari per il corretto funzionamento del sistema.
+
+All’interno delle proprietà del server in DNS Manager, è possibile visualizzare il server DNS al quale vengono inoltrate le richieste per la risoluzione dei nomi esterni.
+
+![dns-forwarders](asset/img/dns-forwarders.png)
+
+Nelle proprietà della zona, è presente un’opzione che permette di abilitare i trasferimenti di zona (Zone Transfers) verso server appartenenti ad altri domini o a terze parti.
+
+![zone-transfers](asset/img/zone-transfers.png)
+
+Nella sezione Nameserver sono elencati i server *DNS autoritativi* per la zona specificata.
+
+![nameservers](asset/img/nameservers.png)

winserver/009-trust.md

@@ -0,0 +1,32 @@
+# Trust bidirezionale tra domini
+
+Il `trust` rappresenta la relazione di fiducia stabilita tra domini Active Directory, consentendo così agli utenti di un dominio di accedere alle risorse dell’altro. Tale relazione può essere unidirezionale o bidirezionale. Affinché sia possibile configurare un trust, è necessario che siano soddisfatte due condizioni preliminari:
+
+- I DC dei due domini devono essere in grado di comunicare tra loro a livello di rete
+- Deve essere possibile il trasferimento di zona DNS tra i domini coinvolti
+
+## Trasferimento di zona DNS
+
+In `DNS Manager > Properties` della zona che si desidera trasferire, nella tab `Zone Transfers`, è fondamentale assicurarsi che il trasferimento sia consentito solo ai server specificati. Questa operazione deve essere eseguita anche sui server DC dell'altra zona nel caso di un trust bidirezionale. Se in una zona sono presenti più DC, tutti devono essere inclusi nel trasferimento.
+
+![zone-transfer](asset/img/zone-transfers.png)
+
+Sul primo DC, all’interno di `DNS Manager`, nella sezione `Forward Lookup Zones`, è necessario creare una zona secondaria. Utilizzare il nome della zona dell'altro dominio e inserire l'indirizzo IP del server master della zona. A questo punto, la zona dovrebbe replicarsi correttamente.
+
+![forward-lookup-zones](asset/img/forward-lookup-zones.png)
+
+La medesima procedura deve essere ripetuta anche per la zona dell'altro dominio.
+
+## Trust Bidirezionale
+
+Una volta completate le configurazioni DNS, è possibile procedere con la creazione del trust bidirezionale. L’operazione può essere avviata da qualsiasi domain controller di uno dei domini coinvolti:
+
+- Aprire `Active Directory Domains and Trusts`
+- Accedere alle proprietà del dominio, selezionare la scheda `Trust` e scegliere l’opzione `New Trust`
+- Inserire il nome del dominio con cui si intende stabilire la relazione di fiducia
+
+![new-trust](asset/img/new-trust.png)
+
+Nella maggior parte dei casi, si tratta di un `forest trust`
+
+![forest-trust](asset/img/forest-trust.png)

winserver/010-iis.md

@@ -0,0 +1,31 @@
+# Internet Information Services (IIS)
+
+`Internet Information Services` (`IIS`) è un server web sviluppato per la piattaforma Microsoft .NET e operante sui sistemi operativi Windows. È progettato per ospitare applicazioni web sviluppate con ASP.NET e siti web statici. Inoltre, può funzionare come server FTP.
+
+Tra le opzioni di autenticazione integrate, si possono trovare `Basic Authentication`, `ASP.NET Authentication` e `Windows Authentication`. Quest'ultima è particolarmente vantaggiosa in un ambiente Active Directory, in quanto consente agli utenti di autenticarsi automaticamente nelle applicazioni web utilizzando il proprio account di dominio.
+
+## Installazione del ruolo Web Server (IIS)
+
+Per installare IIS, è necessario aggiungere il ruolo `Web Server (IIS)` tramite `Server Manager`.
+
+![iis-role](asset/img/iis-role.png)
+
+Durante la procedura, è possibile selezionare ruoli aggiuntivi per IIS, tra cui:
+
+- WebDAV Publishing
+- Dynamic Content Compression
+- Basic Authentication (plain text)
+- Windows Authentication
+- FTP Server
+
+![additional-features](asset/img/additional-features.png)
+
+## Gestione del server
+
+Lo strumento di gestione `IIS Manager` è accessibile da `Control Panel > Windows Tools`.
+
+![iis-manager](asset/img/iis-manager.png)
+
+Il sito web predefinito sarà raggiungibile all’indirizzo `http://localhost`.
+
+![iis-website](asset/img/iis-website.png)

winserver/011-dc-demote.md

@@ -0,0 +1,51 @@
+# Demote e rimozione di un domain controller
+
+Il `demote` di un domain controller è la procedura che ne rimuove il ruolo di controller di dominio, declassandolo a normale server membro.
+
+## Fasi preliminari
+
+Dal server che si intende rimuovere, ad esempio `DC02`, accedere a `Server Manager`. Selezionare `Remove Roles and Features` e quindi cliccare su `Active Directory Domain Services`.
+
+![remove-roles-and-features](asset/img/remove-roles-and-features.png)
+
+Successivamente, selezionare `Remove Features`.
+
+![remove-ad](asset/img/remove-ad.png)
+
+È comune ricevere un errore che indica che *è necessario eseguire prima il demote* del domain controller.
+
+![demote-dc](asset/img/demote-dc.png)
+
+Cliccare su `Demote this DC` e, infine, selezionare `Proceed with removal`.
+
+![proceed-removal](asset/img/proceed-removal.png)
+
+Nella finestra successiva, inserire la password del nuovo account di amministratore locale che verrà creato automaticamente sul server dopo il demote.
+
+![new-admin-password](asset/img/new-admin-password.png)
+
+Una volta completati questi passaggi, selezionare `Demote` per riportare il server alla modalità di semplice membro del dominio.
+
+## Rimozione della Feature Active Directory Domain Services
+
+Dopo il riavvio e il login, è possibile completare la rimozione della feature `Active Directory Domain Services` tramite `Server Manager`.
+
+Impostare come *server DNS primario* il domain controller rimanente (ad esempio DC01).
+
+A questo punto, è possibile osservare che ora è presente un solo domain controller nella struttura e che DC02 è stato declassato a normale computer.
+
+![single-dc](asset/img/single-dc.png)
+
+![normal-pc](asset/img/normal-pc.png)
+
+È necessario accedere a `Active Directory Sites and Services` sul domain controller rimanente (DC01) e rimuovere manualmente il riferimento all'ormai ex controller di dominio (DC02).
+
+![active-directory-sites-and-services](asset/img/active-directory-sites-and-services.png)
+
+## Riassegnazione del server
+
+DC02 può essere ora riassegnato a nuove funzioni, ad esempio puó essere configurato come file server o server RDP. Nel caso specifico, rinominare il server in FS-RDP01 e configurarlo secondo le nuove esigenze operative.
+
+## Record DNS
+
+Infine, sul DC01, è necessario verificare che i record DNS siano stati aggiornati correttamente in seguito alle modifiche apportate. Assicurarsi che non siano presenti riferimenti obsoleti.

winserver/012-ca.md

@@ -0,0 +1,36 @@
+# Certification Authority
+
+La `Certification Authority` (`CA`) è essenziale per la gestione dei certificati `SSL`, utilizzati per autenticare utenti e computer, nonché per garantire la sicurezza di siti web e applicazioni.
+
+La CA di Windows può essere configurata per essere pubblica, esponendo la macchina su Internet, ma generalmente opera in modalità locale.
+
+## Installazione CA Enterprise
+
+L’installazione di una `CA Enterprise` richiede l’utilizzo di un server membro. Non è consigliato installare il ruolo su un Domain Controller, in quanto quest’ultimo dovrebbe essere dedicato esclusivamente alle funzioni di controller di dominio.
+
+Accedere a `Server Manager`, selezionare `Manage > Add Roles and Features` e procedere con l’installazione del ruolo `Active Directory Certificate Services`. Durante la procedura, aggiungere anche il ruolo `Certification Authority Web Enrollment`.
+
+![ca-web-enrollment](asset/img/ca-web-enrollment.png)
+
+Al termine dell’installazione, avviare la configurazione di `Active Directory Certificate Services`.
+
+![config-adcs](asset/img/config-adcs.png)
+
+Nella schermata di configurazione, selezionare i seguenti servizi:
+
+- Certification Authority
+- Certification Authority Web Enrollment
+
+![ca-services-to-enable](asset/img/ca-services-to-enable.png)
+
+Scegliere `Enterprise CA` come tipo di autorità di certificazione. Successivamente, selezionare `Root CA` e procedere con la creazione di una nuova `private key`.
+
+![enterprise-ca](asset/img/enterprise-ca.png)
+
+Una volta completata la configurazione, la CA risulta accessibile tramite l’interfaccia web di enrollment all’indirizzo:
+
+```txt
+http://localhost/certsrv
+```
+
+Da questa pagina è possibile gestire e visualizzare i certificati emessi.

winserver/013-shadow-copy.md

@@ -0,0 +1,69 @@
+# Shadow Copy
+
+Le `Shadow Copy` sono una funzionalità che consente di creare snapshot di file e cartelle. Attraverso questa funzione, è possibile recuperare file, cartelle e modifiche precedenti, accedendo alle versioni salvate in momenti specifici.
+
+Per utilizzare le Shadow Copy, è comune configurare due dischi distinti:
+
+- `Volume DATA`: contiene i dati attivi
+- `Volume SHADOW`: dedicato allo storage degli snapshot
+
+![shadow-volume](asset/img/shadow-volume.png)
+
+## Shadow Copy sullo stesso disco
+
+Per configurare Shadow Copy, accedere a `Volume DATA > Properties > Configure Shadow Copy`.
+
+### Pianificazione
+
+È possibile abilitare le Shadow Copy direttamente sul volume principale. Dalle impostazioni, è inoltre possibile schedulare gli snapshot secondo una cadenza prestabilita.
+
+![enable-shadow-copy](asset/img/enable-shadow-copy.png)
+
+La pianificazione consente di definire orari e giorni specifici per la creazione degli snapshot. Ad esempio, è possibile impostare la generazione automatica dal lunedì al venerdì, ogni due ore, nell’intervallo orario compreso tra le 7:00 e le 19:00.
+
+![schedule-shadow-copy](asset/img/schedule-shadow-copy.png)
+
+### Creazione manuale degli snapshot
+
+Oltre alla pianificazione automatica, è possibile forzare la creazione di uno snapshot in qualsiasi momento, cliccando il pulsante `Create Now`.
+
+![create-shadow-copy](asset/img/create-shadow-copy.png)
+
+### Recupero delle versioni precedenti
+
+Per accedere alle versioni precedenti di file o cartelle, è sufficiente:
+
+- Fare clic con il tasto destro su un file o una cartella all’interno del volume
+- Selezionare `Properties > Previous Versions`
+
+In questa sezione, vengono visualizzate le versioni salvate. È possibile aprire e consultare il contenuto di ogni snapshot, nonché ripristinare file o cartelle a una versione precedente.
+
+Qualora si condivida la directory all'interno del volume, è consigliabile visualizzare le Shadow Copy via rete piuttosto che direttamente dal disco. L’accesso diretto potrebbe infatti restituire risultati non corretti o incompleti.
+
+![network-shadow-copy](asset/img/network-shadow-copy.png)
+
+## Riallocazione delle Shadow Copy
+
+Prima di procedere con la riallocazione, è necessario disattivare il servizio Shadow Copy sul volume di origine
+
+![disable-shadow-copy](asset/img/disable-shadow-copy.png)
+
+Lo spostamento delle Shadow Copy su un volume dedicato richiede l’utilizzo del prompt dei comandi con privilegi di amministratore:
+
+```cmd
+vssadmin Add ShadowStorage /For=D: /On=E: /MaxSize=100%
+```
+
+Dove:
+
+- `/For=D:` indica il volume di origine per cui vengono gestite le Shadow Copy
+- `/On=E:` specifica il volume di destinazione su cui verranno allocate le Shadow Copy
+- `/MaxSize=100%` imposta lo spazio massimo dedicato alle Shadow Copy nel volume di destinazione
+
+![e-shadow-copy](asset/img/e-shadow-copy.png)
+
+Abilitare infine il servizio dal disco D. A questo punto, tutti gli snapshot si troveranno sul disco E.
+
+![enable-remote-shadow-copy](asset/img/enable-remote-shadow-copy.png)
+
+Le Shadow Copy, in quanto spazio vuoto, non verranno incluse nei processi di backup standard. Per garantire la conservazione degli snapshot, è necessario eseguire una copia settore per settore dell’intero disco.

winserver/014-dfs.md

@@ -0,0 +1,38 @@
+# Distributed File System Replica
+
+Il `Distributed File System` (`DFS`) è una funzionalità utilizzata per garantire la ridondanza dei file server, consentendo agli altri server di subentrare in caso di malfunzionamento di uno di essi. Inoltre, il DFS facilita la migrazioni di File Server con versioni obsolete di Windows Server a versioni più recenti, mantenendo i permessi associati alle cartelle.
+
+![dfs-replication](asset/img/dfs-replication.png)
+
+## Prerequisiti e installazione
+
+Per attivare la replica DFS, è necessario disporre di almeno due server. La funzionalità deve essere installata su entrambi i server coinvolti.
+
+- Accedere a `Server Manager`
+- Selezionare `Add Roles and Features`
+- Aggiungere la funzionalità `DFS Replication`
+
+## Configurazione della replica
+
+Dopo l’installazione su entrambi i server, procedere come segue:
+
+- Aprire `DFS Management` da Windows Tools. Questo strumento consente di creare e gestire la struttura di replica
+- Creare un nuovo gruppo di replica
+
+![new-replication-group](asset/img/new-replication-group.png)
+
+- Scegliere `Multipurpose Replication`, che consente la replica tra due o più server
+
+![multipurpose-replication-group](asset/img/multipurpose-replication-group.png)
+
+- Aggiungere i server che parteciperanno al gruppo di replica
+
+![add-member](asset/img/add-member.png)
+
+- Selezionare `Full Mesh` come tipo di replica: ogni membro replicherà i dati su tutti gli altri membri del gruppo
+- Designare il file server principale come membro primario
+- Impostare il local path del disco contenente i dati sul file server e abilitare il percorso sul server di destinazione. In questo modo, i dati verranno replicati in tempo reale, *inclusi i permessi associati ai file e alle cartelle*
+
+![created-dfs](asset/img/created-dfs.png)
+
+Una volta configurata la struttura, le modifiche apportate ai dati da uno qualsiasi dei server coinvolti verranno automaticamente replicate su tutti gli altri membri del gruppo. Non è rilevante da quale server vengano effettuate le modifiche: la sincronizzazione avviene in modo trasparente e bidirezionale.

winserver/016-rdp.md

@@ -0,0 +1,48 @@
+# Remote Desktop
+
+Assicurasi che il `Remote Desktop` sia attivo da `Advance System Settings`. Buona prassi non installare il ruolo di RDP Server sul DC.
+
+![rdp](asset/img/rdp.png)
+
+Le licenze Terminal Server per gli users devono essere acquistate e successivamente attivate sul server RDP.
+
+## Aggiunta ruolo Remote Desktop
+
+Per attivare il ruolo di server RDP, procedere come segue:
+
+- Aprire `Server Manager > Add Roles and Features`
+- Selezionare `Remote Desktop Services Installation`
+
+![rdp-services-installation](asset/img/rdp-services-installation.png)
+
+- Scegliere l’opzione `Quick Start` per configurare i servizi su un singolo server
+
+![rdp-quick-start](asset/img/rdp-quick-start.png)
+
+- Selezionare `Session-based desktop deployment` come modalità di distribuzione
+
+![session-based-desktop-deployment](asset/img/session-based-desktop-deployment.png)
+
+> Dopo l’installazione del ruolo, è necessario inserire la licenza entro 119 giorni per garantire la continuità del servizio.
+
+Dal DC, aggiungere gli utenti autorizzati al gruppo `Remote Desktop Users`. L’omissione di questo passaggio impedisce agli utenti di effettuare il login tramite desktop remoto.
+
+## License Manager
+
+Per configurare il gestore delle licenze, accedere a `Server Manager > Remote Desktop Services` e selezionare `RD Licensing`. Aggiungere il server come gestore delle licenze seguendo la procedura guidata visualizzata.
+
+![license-manager](asset/img/license-manager.png)
+
+Al termine dell’installazione, è possibile attivare il server e inserire le `CAL` tramite `Windows Tools > Remote Desktop Licensing Manager`. Si consiglia di utilizzare le `CAL User` anziché le CAL Device, poiché le prime sono associate all’utente e possono essere rimosse singolarmente e riutilizzate secondo necessità.
+
+![activate-rdp-server](asset/img/activate-rdp-server.png)
+
+## RDP Web Access
+
+Per configurare l’accesso via web, accedere a `Server Manager > Remote Desktop Services` e selezionare `Edit Deployment Settings`. Nella scheda `RD Web Access` è possibile visualizzare l’URL del Web Access Server, che consente l’accesso tramite browser alle risorse pubblicate.
+
+![edit-deployment-settings](asset/img/edit-deployment-settings.png)
+
+È possibile aggiungere ulteriori risorse secondo le esigenze specifiche. Utilizzando questa modalità, non viene esposta la porta RDP (3389), ma solo la porta 443 (HTTPS).
+
+![rdp-web-access](asset/img/rdp-web-access.png)