Question sur l'authentification intégrée, Kerberos? NTLM ?
1 réponse
bigstyle
Bonjour,
lorsque l'on parle d'authentification integré dans windows 2000, l'on parle
de NTLM ou de Kerberos ?
J'avais compris que c'etait NTLM mais une question du cours que je lis m'a
mis un doute...
De plus, quelqu'un saurait m'expliquer pourquoi le protocole NTLM est
capable de passer au travers des firewall mais pas des proxys et le
protocole Kerberos est capable de passer à travers un proxy mais pas un
firewall ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stanislas Quastana [MS]
Bonjour,
lorsque l'on parle d'authentification integré dans windows 2000, l'on parle de NTLM ou de Kerberos ? Les 2. Après cela dépend de l'infrastructure en place et de la version de
Windows sur le poste client.
De plus, quelqu'un saurait m'expliquer pourquoi le protocole NTLM est capable de passer au travers des firewall mais pas des proxys et le protocole Kerberos est capable de passer à travers un proxy mais pas un firewall ?
NTLM peut passer au travers d'un proxy [enfin, cela dépend du proxy ;-)] : Microsoft ISA Server depuis la version 2000 offre cette fonctionnalité (NTLM Passthrough)
Kerberos (pour la partie authentification) peut parfaitement passer au travers d'un firewall (il suffit d'ouvrir les protocoles UDP/88 et TCP/88)
En fait, au niveau de Kerberos, la problématique se situe plutôt au niveau de la translation d'adresse (NAT : Network Address Traversal) : en fonction de l'implémentation de Kerberos choisie et du choix ou non d'utiliser la validation des adresses IP dans les tickets Kerberos :
Protocols that cannot work with NAT enroute http://www.zvon.org/tmRFC/RFC3027/Output/chapter3.html
"Just as with Kerberos 4, Kerberos 5 tickets are encrypted. Therefore, an ALG cannot be written.
In Kerberos 5, the client specifies a list of IP addresses which the ticket should be valid for, or it can ask for a ticket valid for all IP addresses. By asking for an all-IP-addresses ticket or a ticket containing the NAPT device address, you can get krb5 to work with an NAPT device, although it isn't very transparent (it requires the clients to behave differently than they otherwise would). The MIT krb5 1.0 implementation didn't have any configurability for what IP addresses the client asked for (it always asked for the set of its interface addresses) and did not interact well with NAT. The MIT krb5 1.1 implementation allows you to put "noaddresses" somewhere in krb5.conf to request all-IP-addresses-valid tickets.
The K5 ticket (response) contains IP addresses, as requested by the client node, from which the ticket is to be considered valid. If the services being accessed with Kerberos authentication are on the public side of the NAT, then the Kerberos authentication will fail because the IP address used by the NAT (basic NAT or NAPT) is not in the list of acceptable addresses.
There are two workarounds in Kerberos 5 both of which reduce the security of the tickets.
==> The first is to have the clients in NAPT private realm specify the public IP address of the NAPT in the ticket's IP list. But this leads to the same security problem detailed for K4. Plus, it is not obvious for the client in the private domain to find out the public IP Address of the NAPT. That would be a change of application behavior on end-host.
==> The second method is to remove all IP addresses from the K5 tickets but this now makes theft of the ticket even worse since the tickets can be used from anywhere. Not just from within the private network. »
A partir du SP3 de Windows 2000, par défaut, les adresses IP des clients ne sont plus envoyées dans la requête.
Pour rajouter l'adresse IP dans les requêtes Kerberos, il suffit de positionner à 1 la valeur ClientIPAdresses sous la clé : HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Lsa Kerberos Parameters
Cependant, il est à noter que même si cette valeur est positionnée à 1, le KDC, par défaut, ne fait aucune vérification sur l'adresse IP contenu dans la requête. Pour que le KDC fasse la vérification, il faut positionner les 2 valeurs de registre suivantes sur le KDC : KdcUseClientAddresses=1 et KdcDontCheckAddresses=0
Pour Windows 2003, Il n'y a pas de changement de comportement par rapport à Windows 2000 SP3. La clé ClientIPAdresses existe également et fonctionne comme Windows XP.
Note : la principale architecture combinant NAT et Kerberos non supportée par Microsoft est aujourd'hui la communication Inter contrôleurs de domaines Active Directory.
Cordialement -- Stanislas Quastana, CISSP Architecte Infrastructure Division Développeurs et Plate-Forme d'Entreprise Microsoft France
"bigstyle" wrote in message news:41c164ef$0$19440$
Bonjour,
lorsque l'on parle d'authentification integré dans windows 2000, l'on parle de NTLM ou de Kerberos ?
J'avais compris que c'etait NTLM mais une question du cours que je lis m'a mis un doute...
De plus, quelqu'un saurait m'expliquer pourquoi le protocole NTLM est capable de passer au travers des firewall mais pas des proxys et le protocole Kerberos est capable de passer à travers un proxy mais pas un firewall ?
Je continue mes recherches de mon coté aussi.
Merci
Bonjour,
lorsque l'on parle d'authentification integré dans windows 2000, l'on
parle
de NTLM ou de Kerberos ?
Les 2. Après cela dépend de l'infrastructure en place et de la version de
Windows sur le poste client.
De plus, quelqu'un saurait m'expliquer pourquoi le protocole NTLM est
capable de passer au travers des firewall mais pas des proxys et le
protocole Kerberos est capable de passer à travers un proxy mais pas un
firewall ?
NTLM peut passer au travers d'un proxy [enfin, cela dépend du proxy ;-)] :
Microsoft ISA Server depuis la version 2000 offre cette fonctionnalité (NTLM
Passthrough)
Kerberos (pour la partie authentification) peut parfaitement passer au
travers d'un firewall (il suffit d'ouvrir les protocoles UDP/88 et TCP/88)
En fait, au niveau de Kerberos, la problématique se situe plutôt au niveau
de la translation d'adresse (NAT : Network Address Traversal) : en fonction
de l'implémentation de Kerberos choisie et du choix ou non d'utiliser la
validation des adresses IP dans les tickets Kerberos :
Protocols that cannot work with NAT enroute
http://www.zvon.org/tmRFC/RFC3027/Output/chapter3.html
"Just as with Kerberos 4, Kerberos 5 tickets are encrypted. Therefore,
an ALG cannot be written.
In Kerberos 5, the client specifies a list of IP addresses which the ticket
should be valid for, or it can ask for a ticket valid for all IP addresses.
By asking for an all-IP-addresses ticket or a ticket containing the NAPT
device address, you can get krb5 to work with an NAPT device, although it
isn't very transparent (it requires the clients to behave differently than
they otherwise would). The MIT krb5 1.0 implementation didn't have any
configurability for what IP addresses the client asked for (it always asked
for the set of its interface addresses) and did not interact well with NAT.
The MIT krb5 1.1 implementation allows you to put "noaddresses" somewhere in
krb5.conf to request all-IP-addresses-valid tickets.
The K5 ticket (response) contains IP addresses, as requested by the client
node, from which the ticket is to be considered valid. If the services
being accessed with Kerberos authentication are on the public side of the
NAT, then the Kerberos authentication will fail because the IP address used
by the NAT (basic NAT or NAPT) is not in the list of acceptable addresses.
There are two workarounds in Kerberos 5 both of which reduce the security of
the tickets.
==> The first is to have the clients in NAPT private realm specify the
public IP address of the NAPT in the ticket's IP list. But this leads to
the same security problem detailed for K4. Plus, it is not obvious for the
client in the private domain to find out the public IP Address of the NAPT.
That would be a change of application behavior on end-host.
==> The second method is to remove all IP addresses from the K5 tickets but
this now makes theft of the ticket even worse since the tickets can be used
from anywhere. Not just from within the private network. »
A partir du SP3 de Windows 2000, par défaut, les adresses IP des clients ne
sont plus envoyées dans la requête.
Pour rajouter l'adresse IP dans les requêtes Kerberos, il suffit de
positionner à 1 la valeur ClientIPAdresses sous la clé :
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Control
Lsa
Kerberos
Parameters
Cependant, il est à noter que même si cette valeur est positionnée à 1, le
KDC, par défaut, ne fait aucune vérification sur l'adresse IP contenu dans
la requête.
Pour que le KDC fasse la vérification, il faut positionner les 2 valeurs de
registre suivantes sur le KDC : KdcUseClientAddresses=1 et
KdcDontCheckAddresses=0
Pour Windows 2003, Il n'y a pas de changement de comportement par rapport à
Windows 2000 SP3. La clé ClientIPAdresses existe également et fonctionne
comme Windows XP.
Note : la principale architecture combinant NAT et Kerberos non supportée
par Microsoft est aujourd'hui la communication Inter contrôleurs de domaines
Active Directory.
Cordialement
--
Stanislas Quastana, CISSP
Architecte Infrastructure
Division Développeurs et Plate-Forme d'Entreprise
Microsoft France
"bigstyle" <bigstyle@dlaballe.cjb.net> wrote in message
news:41c164ef$0$19440$626a14ce@news.free.fr...
Bonjour,
lorsque l'on parle d'authentification integré dans windows 2000, l'on
parle
de NTLM ou de Kerberos ?
J'avais compris que c'etait NTLM mais une question du cours que je lis m'a
mis un doute...
De plus, quelqu'un saurait m'expliquer pourquoi le protocole NTLM est
capable de passer au travers des firewall mais pas des proxys et le
protocole Kerberos est capable de passer à travers un proxy mais pas un
firewall ?
lorsque l'on parle d'authentification integré dans windows 2000, l'on parle de NTLM ou de Kerberos ? Les 2. Après cela dépend de l'infrastructure en place et de la version de
Windows sur le poste client.
De plus, quelqu'un saurait m'expliquer pourquoi le protocole NTLM est capable de passer au travers des firewall mais pas des proxys et le protocole Kerberos est capable de passer à travers un proxy mais pas un firewall ?
NTLM peut passer au travers d'un proxy [enfin, cela dépend du proxy ;-)] : Microsoft ISA Server depuis la version 2000 offre cette fonctionnalité (NTLM Passthrough)
Kerberos (pour la partie authentification) peut parfaitement passer au travers d'un firewall (il suffit d'ouvrir les protocoles UDP/88 et TCP/88)
En fait, au niveau de Kerberos, la problématique se situe plutôt au niveau de la translation d'adresse (NAT : Network Address Traversal) : en fonction de l'implémentation de Kerberos choisie et du choix ou non d'utiliser la validation des adresses IP dans les tickets Kerberos :
Protocols that cannot work with NAT enroute http://www.zvon.org/tmRFC/RFC3027/Output/chapter3.html
"Just as with Kerberos 4, Kerberos 5 tickets are encrypted. Therefore, an ALG cannot be written.
In Kerberos 5, the client specifies a list of IP addresses which the ticket should be valid for, or it can ask for a ticket valid for all IP addresses. By asking for an all-IP-addresses ticket or a ticket containing the NAPT device address, you can get krb5 to work with an NAPT device, although it isn't very transparent (it requires the clients to behave differently than they otherwise would). The MIT krb5 1.0 implementation didn't have any configurability for what IP addresses the client asked for (it always asked for the set of its interface addresses) and did not interact well with NAT. The MIT krb5 1.1 implementation allows you to put "noaddresses" somewhere in krb5.conf to request all-IP-addresses-valid tickets.
The K5 ticket (response) contains IP addresses, as requested by the client node, from which the ticket is to be considered valid. If the services being accessed with Kerberos authentication are on the public side of the NAT, then the Kerberos authentication will fail because the IP address used by the NAT (basic NAT or NAPT) is not in the list of acceptable addresses.
There are two workarounds in Kerberos 5 both of which reduce the security of the tickets.
==> The first is to have the clients in NAPT private realm specify the public IP address of the NAPT in the ticket's IP list. But this leads to the same security problem detailed for K4. Plus, it is not obvious for the client in the private domain to find out the public IP Address of the NAPT. That would be a change of application behavior on end-host.
==> The second method is to remove all IP addresses from the K5 tickets but this now makes theft of the ticket even worse since the tickets can be used from anywhere. Not just from within the private network. »
A partir du SP3 de Windows 2000, par défaut, les adresses IP des clients ne sont plus envoyées dans la requête.
Pour rajouter l'adresse IP dans les requêtes Kerberos, il suffit de positionner à 1 la valeur ClientIPAdresses sous la clé : HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Lsa Kerberos Parameters
Cependant, il est à noter que même si cette valeur est positionnée à 1, le KDC, par défaut, ne fait aucune vérification sur l'adresse IP contenu dans la requête. Pour que le KDC fasse la vérification, il faut positionner les 2 valeurs de registre suivantes sur le KDC : KdcUseClientAddresses=1 et KdcDontCheckAddresses=0
Pour Windows 2003, Il n'y a pas de changement de comportement par rapport à Windows 2000 SP3. La clé ClientIPAdresses existe également et fonctionne comme Windows XP.
Note : la principale architecture combinant NAT et Kerberos non supportée par Microsoft est aujourd'hui la communication Inter contrôleurs de domaines Active Directory.
Cordialement -- Stanislas Quastana, CISSP Architecte Infrastructure Division Développeurs et Plate-Forme d'Entreprise Microsoft France
"bigstyle" wrote in message news:41c164ef$0$19440$
Bonjour,
lorsque l'on parle d'authentification integré dans windows 2000, l'on parle de NTLM ou de Kerberos ?
J'avais compris que c'etait NTLM mais une question du cours que je lis m'a mis un doute...
De plus, quelqu'un saurait m'expliquer pourquoi le protocole NTLM est capable de passer au travers des firewall mais pas des proxys et le protocole Kerberos est capable de passer à travers un proxy mais pas un firewall ?
