Ce article a été traduit automatiquement. (Clause de non responsabilité)
SSO pour les authentifications Basic, Digest et NTLM
La configuration de l’authentification unique (SSO) dans NetScaler et NetScaler Gateway peut être activée au niveau global et également par niveau de trafic. Par défaut, la configuration SSO est désactivée et un administrateur peut activer le SSO par trafic ou globalement. Du point de vue de la sécurité, Citrix recommande aux administrateurs de désactiver globalement le SSO et de l’activer par trafic. Cette amélioration vise à rendre la configuration SSO plus sécurisée en déshonorant certains types de méthodes SSO à l’échelle mondiale.
Remarque :
à partir de la version 13.0 de la fonctionnalité NetScaler build 64.35 et versions ultérieures, les types de SSO suivants ne sont pas respectés à l’échelle mondiale.
- Authentification basique
- Authentification Digest Access
- NTLM sans négociation, clé NTLM2 ou signe de négociation
Types de SSO non impactés
Les types de SSO suivants ne sont pas concernés par cette amélioration.
- Authentification Kerberos
- Authentification SAML
- Authentification par formulaire
- Authentification du porteur OAuth
- NTLM avec clé Negotiate NTLM2 ou signe de négociation
Configurations SSO affectées
Voici les configurations SSO impactées (non honorées).
Configurations globales
set tmsessionparam -SSO ON
set vpnparameter -SSO ON
add tmsessionaction tm_act -SSO ON
add vpn sessionaction tm_act -SSO ON
Configurations par trafic
add vpn trafficaction tf_act http -SSO ON
add tm trafficaction tf_act -SSO ON
Vous pouvez activer/désactiver l’option SSO dans son ensemble et ne pouvez pas modifier les types d’SSO individuels.
Mesures de sécurité à appliquer
Dans le cadre des mesures de sécurité, les types SSO sensibles à la sécurité ne sont pas respectés dans la configuration globale mais ne sont autorisés que par le biais d’une configuration Traffic Action. Ainsi, si un serveur principal attend Basic, Digest ou NTLM sans clé Negotiate NTLM2 ni Negotiate Sign, l’administrateur ne peut autoriser l’authentification unique que par le biais de la configuration suivante.
Action en matière de circulation
add vpn trafficaction tf_act http -SSO ON
add tm trafficaction tf_act -SSO ON
Stratégie de trafic
add tm trafficpolicy <name> <rule> tf_act
add vpn trafficpolicy <name> <rule> tf-act
L’administrateur doit configurer une règle appropriée pour la stratégie de trafic afin de s’assurer que le SSO est activé uniquement pour le serveur principal de confiance.
AAA-TM
Scénarios basés sur la configuration globale :
set tmsessionparam -SSO ON
Solution :
add tm trafficaction tf_act -SSO ON
add tm trafficpolicy tf_pol true tf_act
Liez la stratégie de trafic suivante à tous les serveurs virtuels LB où SSO est attendu :
bind lb vserver <LB VS Name> -policy tf_pol -priority 65345
Scénarios basés sur la configuration de stratégie de session :
add tmsessionaction tm_act -SSO ON
add tmsession policy <name> <rule> tm_act
add tm trafficaction tf_act -SSO ON
add tm trafficpolicy tf_pol <same rule as session Policy> tf_act
Points à noter :
-
L’utilisateur/le groupe NetScaler AAA pour la session précédente doit être remplacé par une stratégie de trafic.
-
Liez la stratégie suivante aux serveurs virtuels d’équilibrage de charge pour la stratégie de session précédente,
bind lb vserver [LB VS Name] -policy tf_pol -priority 65345
- Si une stratégie de trafic avec une autre priorité est configurée, la commande précédente ne sert pas correctement.
La section suivante traite des scénarios basés sur un conflit avec plusieurs stratégies de trafic associées à un trafic :
Pour un trafic TM particulier, une seule stratégie de trafic TM est appliquée. En raison de la configuration globale des modifications des fonctionnalités SSO, l’application d’une stratégie de trafic TM supplémentaire de faible priorité peut ne pas être applicable dans le cas où une stratégie de trafic TM à priorité élevée (qui ne nécessite pas de configuration SSO) est déjà appliquée. La section suivante décrit la méthode permettant de s’assurer que de tels cas sont traités.
Considérez que les trois stratégies de trafic suivantes avec une priorité plus élevée sont appliquées au serveur virtuel d’équilibrage de charge (LB) :
add tm trafficaction tf_act1 <Addition config>
add tm trafficaction tf_act2 <Addition config>
add tm trafficaction tf_act3 <Addition config>
add tm trafficpolicy tf_pol1 <rule1> tf_act1
add tm trafficpolicy tf_pol2 <rule2> tf_act2
add tm trafficpolicy tf_pol3 <rule3> tf_act3
bind lb vserver <LB VS Name> -policy tf_pol1 -priority 100
bind lb vserver <LB VS Name> -policy tf_pol2 -priority 200
bind lb vserver <LB VS Name> -policy tf_pol3 -priority 300
Méthode sujette aux erreurs - Pour résoudre la configuration SSO globale, vous ajoutez la configuration suivante :
add tm trafficaction tf_act_default -SSO ON
add tm trafficpolicy tf_pol_default true tf_act_default
bind lb vserver <LB VS Name> -policy tf_pol_default -priority 65345
Remarque : La modification précédente peut rompre l’authentification unique pour le trafic qui touche <tf_pol1/tf_pol2/tf_pol3> comme pour ce trafic, stratégie de trafic
Méthode correcte - Pour atténuer ce problème, la propriété SSO doit être appliquée individuellement pour chacune des actions de trafic correspondantes :
Par exemple, dans le scénario précédent, pour que l’authentification unique se produise pour le trafic touchant tf_pol1/tf_pol3, la configuration suivante doit être appliquée avec
add tm trafficaction tf_act1 <Addition config> -SSO ON
add tm trafficaction tf_act3 <Addition config> -SSO ON
Boîtiers NetScaler Gateway
Scénarios basés sur la configuration globale :
set vpnparameter -SSO ON
Solution :
add vpn trafficaction vpn_tf_act http -SSO ON
add vpn trafficpolicy vpn_tf_pol true vpn_tf_act
bind the following traffic policy to all VPN virtual server where SSO is expected:
bind vpn vserver vpn_vs -policy vpn_tf_pol -priority 65345
Scénarios basés sur la configuration de stratégie de session :
add vpn sessionaction vpn_sess_act -SSO ON
add vpnsession policy <name> <rule> vpn_sess_act
Points à noter :
-
L’utilisateur/le groupe NetScaler AAA pour la session précédente doit être remplacé par une stratégie de trafic.
-
Liez la stratégie suivante aux serveurs virtuels LB pour la stratégie de session précédente,
bind lb virtual server [LB VS Name] -policy tf_pol -priority 65345. -
Si une stratégie de trafic avec une autre priorité est configurée, la commande précédente ne sert pas correctement. La section suivante traite des scénarios basés sur un conflit avec plusieurs stratégies de trafic associées au trafic.
Scénarios fonctionnels basés sur un conflit avec plusieurs stratégies de trafic associées à un trafic :
Pour un trafic NetScaler Gateway spécifique, une seule stratégie de trafic VPN est appliquée. En raison du paramétrage global des modifications des fonctionnalités SSO, l’application d’une stratégie de trafic VPN supplémentaire avec une faible priorité peut ne pas être applicable s’il existe d’autres stratégies de trafic VPN avec une priorité élevée qui n’ont pas de configuration SSO requise.
La section suivante décrit la méthode permettant de s’assurer que de tels cas sont traités :
Supposons qu’il existe trois stratégies de trafic avec une priorité plus élevée appliquées à un serveur virtuel VPN :
add vpn trafficaction tf_act1 <Addition config>
add vpn trafficaction tf_act2 <Addition config>
add vpn trafficaction tf_act3 <Addition config>
add vpn trafficpolicy tf_pol1 <rule1> tf_act1
add vpn trafficpolicy tf_pol2 <rule2> tf_act2
add vpn trafficpolicy tf_pol3 <rule3> tf_act3
bind vpn vserver <VPN VS Name> -policy tf_pol1 -priority 100
bind vpn vserver <VPN VS Name> -policy tf_pol2 -priority 200
bind vpn vserver <VPN VS Name> -policy tf_pol3 -priority 300
Méthode sujette aux erreurs : Pour résoudre la configuration SSO globale, vous ajoutez la configuration suivante :
add vpn trafficaction tf_act_default -SSO ON
add vpn trafficpolicy tf_pol_default true tf_act_default
bind vpn vserver <VPN VS Name> -policy tf_pol_default -priority 65345
Remarque : La modification précédente peut rompre l’authentification unique pour le trafic qui atteint, <tf_pol1/tf_pol2/tf_pol3> comme pour ce trafic, stratégie de trafic
Méthode correcte : pour atténuer ce problème, la propriété SSO doit être appliquée individuellement pour chacune des actions de trafic correspondantes.
Par exemple, dans le scénario précédent, pour que l’authentification unique se produise pour le trafic touchant tf_pol1/tf_pol3, la configuration suivante doit être appliquée avec
add vpn trafficaction tf_act1 [Additional config] -SSO ON
add vpn trafficaction tf_act3 [Additional config] -SSO ON