Les applications NON-NTLM


On parle en anglais du principe NTLM Aware.

Lorsque le service proxy est connecté à un serveur Active Directory, il s’assure que les connexions émanent bien d’une session dite NTLM.
La plupart des navigateurs Internet ( opéra, FireFox, Internet Explorer, Chrome) utilisent les API Microsoft afin de fournir les jetons d’identification nécessaires.

Certains applications comme celles développées en Java, des applications de contrôle à distance ou certains antivirus n’utilisent pas cette norme.

Ainsi, ne possédant pas le jeton d’identification NTLM, le proxy rejettera sans cesse la demande d’accès.

Les ACLS peuvent aider.

Le principe des ACLs permet d’indiquer au proxy que pour une destination précise la demande d’authentification ne sera pas effectuée.
Cette méthode assure 90% des problèmes d’applications métiers qui nécessite une connexion à un DataCenter Internet.
Prenez l’exemple de Symantec Cloud Security afin de créer la règle ACL qui permettra au proxy « d’autoriser » les accès vers une liste de destination.

Voir aussi: Action rapide: passer outre l’authentification NTLM.

Dans le cas des ACLs, le mode « Autoriser » ne veut pas dire que tout est possible.
Ce mode n’adresse que le système d’identification où la règle oblige le proxy à autoriser l’accès sans jeton d’identification.

Bien sûr comme le proxy n’identifie plus, les comptes utilisateurs ne seront pas indiqués dans les logs d’accès et statistiques.
Les règles par groupe utilisateurs Active Directory n’auront plus d’effets puisque le proxy ne sera pas en mesure d’identifier l’accès…

Les UsersAgents, un raccourci.

On peut aussi créer des règles en fonction de la signature du logiciel qui va se connecter au Proxy.
Si vous avez la connaissance de l’UserAgent utilisé par l’application métier, vous pouvez utiliser dans Artica la section dédié aux Navigateurs Internet.

Pour ce faire, inspirez-vous de l’exemple pour permettre à iTunes de passer outre la barrière d’identification du Proxy.

 

Laissez un commentaire