Journal Kerberos du MIT + windows 2000 ?

Posté par  .
Étiquettes : aucune
0
23
juil.
2003
Bonjour tous, je cherche un système d'authentification unifiée entre Linux et Windows 2000 permettant par la suite d'utiliser une authentification a carte a puce.

J'ai pensé à Kerberos et j'ai déjà réussit à mettre en place le KDC, j'arrive à obtenir un ticket valide depuis les postes Linux de mon réseau et à utiliser les outils kerberisés (krlogin, telnet, ...)

Cependant, l'authentification depuis Windows 2000 me pose problème, si vous avez déjà eu ce genre d'expérience ou si vous avez une autre solution permettant ce genre d'authentification (avec possibilité d'extention vers une authentification avec carte a puce), je suis ouvert à tout conseil.

Pour ceux qui chercent la même chose, voici quelques liens pour commencer :

LDAP + kerberos
http://www.bayour.com/LDAPv3-HOWTO.html

Configuration de Windows 2000 pour kerberos :
http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp

Si vous en avez d'autres, merci de les poster ici !
  • # Re: Kerberos du MIT + windows 2000 ?

    Posté par  (site web personnel) . Évalué à 1.

    Windows2000 a une implémentation LDAP pas franchement RFC, nottament au niveau de l'InetOrgPerson...qui n'existe pas (c'est une "nouveauté" de l'AD au niveau 2003 server).

    As tu fait une relation d'approbation entre tes royaumes kerberos?

    Qu'est ce qui ne marche pas?
    • [^] # Re: Kerberos du MIT + windows 2000 ?

      Posté par  . Évalué à 1.

      je n'ai qu'un realm, c'est grave ?

      Ce qui ne marche pas :
      Windows 2000 refuse d'authentifier un utilisateur sur le kdc
      Je ne vois pas de message d'erreur dans les logs (pas de "Client not found in Kerberos database" ni de "Server not found in Kerberos database") et je ne trouve pas comment voir la raison du rejet par Windows 2000.

      Le cryptage utilisé est du DES (simple) crc, pour ceux que ça interesse, Windows 2000 ne supporte pas le DES3 quand il interagit avec le kerberos du MIT.

      Si tu as une référence de documentation ou de livre, je suis preneur.
      J'ai lu "Kerberos a network authentication system" de Brian Tung qui expliques assez bien le fonctionnement de kerberos (coté unix surtout) et ses possibilités mais il est un peu léger, ça n'est pas un support de référence.

      Pour le LDAP pas RFC, je vais y toucher avec une fois que kerberos fonctionne.

      Merci de ta réponse Matheo
      • [^] # Re: Kerberos du MIT + windows 2000 ?

        Posté par  (site web personnel) . Évalué à 1.

        Matho, pas matheo ^^

        MmMMm
        1 - verifie ton SP sur ton 2000 : met le sp4 si possible.
        2 - vérifie la synchro horaire entre tes machines : elles doivent avoir un delta de 5 min maxi (0 c'est bien ^^ ps synchronize le serveur racine de ta foret 2000 et pas le kdc 2000, car c'est le serveur racine de ta foret qui est source horaire pour ton AD)

        Ensuite on peut essayer d'activer le log au niveau de ton KDC afin de voir pourquoi il jette tes clients en suivant la fiche suivante.

        *********
        HOW TO: Enable Kerberos Event Logging (262177)
        The information in this article applies to:

        * Microsoft Windows 2000 Server
        * Microsoft Windows 2000 Advanced Server
        * Microsoft Windows 2000 Professional
        * Microsoft Windows 2000 Datacenter Server

        This article was previously published under Q262177
        IN THIS TASK

        * SUMMARY
        o Enabling Kerberos Event Logging on a Specific Computer


        IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:
        256986 Description of the Microsoft Windows Registry

        SUMMARY


        Windows 2000 offers the capability of tracing detailed Kerberos events through the event log mechanism. You can use this information when you troubleshoot Kerberos. This article describes how to enable Kerberos event logging.

        WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

        back to the top
        Enabling Kerberos Event Logging on a Specific Computer

        1. Start Registry Editor.
        2. Add the following registry value:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters


        Registry Value: LogLevel
        Value Type: REG_DWORD
        Value Data: 0x1

        If the Parameters subkey does not exist, create it.

        Note Remove this registry value when it is no longer needed so that performance is not degraded on the computer. Also, you can remove this registry value to disable Kerberos event logging on a specific computer.
        3. Quit Registry Editor, and then restart the computer.

        You can find any Kerberos-related events in the system log.

        ***************************************************
        ensuite on pourra regarder les erreurs avec les codes ci dessous :
        ***************************************************

        Description of Common Kerberos-Related Errors in Windows 2000 (230476)
        The information in this article applies to:

        * Microsoft Windows 2000 Server
        * Microsoft Windows 2000 Advanced Server
        * Microsoft Windows 2000 Professional
        * Microsoft Windows 2000 Datacenter Server

        This article was previously published under Q230476
        SUMMARY
        Windows 2000 provides support for MIT Kerberos version 5 authentication, as defined in IETF Request For Comment (RFC) 1510. The Kerberos protocol is composed of three sub-protocols. The sub-protocol through which the client pre-sends the ticket for admission to a service is called the Application (AP) Exchange. The sub-protocol through which the KDC distributes a service session key and a ticket for the service is called the Ticket-Granting Service (TGS) Exchange. The sub-protocol through which the client pre-sends the ticket for admission to a service is called the Client/Server (CS) Exchange.

        This article describes common Kerberos version 5-related errors, and includes causes that may be associated with the errors. Note that these errors are associated with Kerberos specifically, not network connectivity.
        MORE INFORMATION
        Common Kerberos version 5-related errors in Hexadecimal:
        0x6 (KRB_ERR_C_PRINCIPAL_UNKNOWN) "Client not found in Kerberos database"
        The KDC could not translate the client principal name from the KDC request into an account in the Active Directory. Generally, verifying whether the client account exists and has propagated to the domain controller that generated the error. Checking Active Directory replication may provide an indication of why the error occurred. It can also be a problem where the name specified is not a recognized User principal name present on the userPrincipalName attribute of the account.
        0x7 (KRB_ERR_S_PRINCIPAL_UNKNOWN) "Server not found in Kerberos database"
        The KDC could not translate the server principal name from the KDC request into an account in the Active Directory. Generally, verifying whether the server account exists and has propagated to the domain controller that generated the error. Checking Active Directory replication may provides an indication of why the error occurred. Also if the server is not at least Windows 2000, there will not be any service principal names registered because that server is not capable of authenticating with Kerberos. In this case, this error can be ignored because the client will then switch to NTLM for authentication.
        0x9 (KDC_ERR_NULL_KEY) "The client or server has a null key"
        Keys should never be null (blank). Even null passwords generate keys because the password is concatenated with other elements to form the key. If a client sees this error, the administrator should reset the password on the account.
        0xE (KDC_ERR_ETYPE_NOTSUPP) "KDC has no support for the encryption type"
        The client tried to use an encryption type that the KDC does not support, for any of the following reasons:

        * The client's account does not have a key of the appropriate encryption type.
        * The KDC (cross-realm trust) account does not have a key of the appropriate encryption type.
        * The requested server account does not have a key of the appropriate encryption type.
        * The type may not be recognized at all, for example, if a new type is introduced. This happens most frequently with MIT compatibility, where an account may not yet have an MIT compatible key. Generally, a password change must occur for the MIT-compatible key to be available.

        0x18 (KDC_ERR_PREAUTH_FAILED) "Pre-authentication information was invalid"
        This indicates failure to obtain ticket, possibly due to the client providing the wrong password.
        0x19 (KDC_ERR_PREAUTH_REQUIRED) "Additional pre-authentication"
        The client did not send pre-authorization, or did not send the appropriate type of pre-authorization, to receive a ticket. The client will retry with the appropriate kind of pre-authorization (the KDC returns the pre-authentication type in the error). Many Kerberos implementations will start off without preauthenticated data and only add it in a subsequent request when it sees this error. In this case, this error can safely be ignored.
        0x25 (KRB_AP_ERR_SKEW) "Clock skew too great"
        There is time discrepancy between client and server or client and KDC.
        0x26 (KRB_AP_ERR_BADADDR) ""Incorrect net address"
        Session tickets include the addresses from which they are valid. This error can occur if the address of the computer sending the ticket is different from the valid address in the ticket. A possible cause of this could be an Internet Protocol (IP) address change. Another possible cause is when a ticket is passed through a proxy server or NAT. The client is unaware of the address scheme used by the proxy server, so unless the program caused the client to request a proxy server ticket with the proxy server's source address, the ticket could be invalid.
        0x29 (KRB_AP_ERR_MODIFIED) "Message stream modified"
        This indicates that the server was unable to decrypt the ticket sent by a client meaning that the server does not know the secret key used to encrypt the ticket, or the client got the ticket from a KDC that did not know the server's key. This can be tested by determining if the server can obtain a ticket to itself, or if anybody else can locate the server. The secure channel used by NTLM is also an indicator of the validity of the password on local machine accounts.
        0x3C (KRB_ERR_GENERIC) "Generic Error"
        A generic error that may be a memory allocation failure. The event logs may be useful if this error occurs.

        *******************

        Enfin, même si je ne suis pas un spécialiste kerberos, je crois bien que tu dois avoir un royaume kerberos pour tes machines Unix (le MIT) et un autre pour ton domaine 2000 (celui de l'Active Directory) et qu'il te faut établir une relation d'approbation (comme pour des domaines NT si tu veux) entre les deux.

        Voila mes 2 sous.
        Donne moi des news ^^
        • [^] # Re: Kerberos du MIT + windows 2000 ?

          Posté par  . Évalué à 1.

          Voici quelques indications pour ceux qui tomberaient sur cette page :

          On peut centraliser les comptes sur un Active Directory avec :
          AD4Unix

          regardez aussi du coté de LAAAD qui propose une bonne méthode de mise en place.

          et le tout fonctionne, authentification des Linux users sur Windows 2000 avec mot de passe unique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.