Port 25 - Communications from the open source community at Microsoft

Comments RSS

1. einhverfr said:

   Very informative, thanks.
   
   Chris Travers
   Metatron Technology Consulting

   posted at 02:08PM 05/10/2006
2. JackCXue said:

   This is great!!! I hope you can bring Tom and Paul to the studio and talk about that topic in depth and Centrify software again.

   posted at 12:38AM 05/16/2006
3. nagnud said:

   Please do bring back Tom and Paul for more detail on their solution. Information about migrating from NIS/NIS+ and LDAP to Centrify would be very helpful. How does their product work with and or support bread and butter nix group management tools such as net groups and auto mounts? Thanks!

   posted at 12:58PM 05/16/2006
4. pmoore said:

   thanks for the positive comments. Hopefully sam will invite us back to dive deep into more interop technology, we certainly enjoyed our first visit
   
   Regarding how we support NIS, netgroup etc. Our product has a NIS gateway that can serve this data up from AD to yp clients that need it. Check out our web site (www.centrify.com)

   posted at 04:26AM 05/17/2006
5. Sam Ramji said:

   Paul - it was a pleasure having you in the lab last month.  It would be great to have you back.
   
   Port 25 readers - if you start a list of questions you'd like to have Paul answer, post them here and I'll use them for the next Paul Moore interview.
   
   Cheers,
   
   Sam

   posted at 11:50PM 05/24/2006
6. fluke said:

   I tried asking this previously but never really got an answer.  So, I will try re-wording it.
   
   According to an FBI computer crime survey, 70% of computer security problems are caused by someone on the inside of the company or organization.  So, it should be no surprise that part of what is taken into consideration is the damage that a disgruntled employee can cause.   As part of minimizing exposer to a disgruntled employee that had administrative rights and the possibly of copying the hashed form of the passwords, we are considering a policy regarding the minimal strength of storing passwords.  Currently, with FOSS PAM modules, any hash function can be choosen for the authentication system including SHA256.  It seems like Centrify is a step backward from this level of flexiablity and requires users leveraging it for single sign-on to accept that passwords will be stored via MD4 hash.
   

   posted at 02:32PM 06/08/2006
7. pmoore said:

   Fluke, you raise a very good point that the perceived stength of crypto algorithms is a moving target.
   
   As a clarifiaction we do not use MD4,we use 128-bit RC4 (I probably mumbled a bit in the talk). This is still generally considered secure although I dont want to sound complacent.
   
   The other point is that because we interoperate with ActiveDirectory we have to use the crypto systems that it supports (it is the one that generates the keys and hashes). In 2000 and 2003 this is 128-bit RC4 (although you can force it to use DES as I pointed out in the talk, but not recommended).
   In Longhorn Microsoft will use AES and SHA with 128 or 256 bit keys; we will then use those. We can then all relax for a bit until compute power moves up another notch and we have to move to even bigger keys.

   posted at 02:31PM 06/09/2006
8. fluke said:

   Taken from: http://support.microsoft.com/?kbid=299656
   
   Windows 2000-based servers and Windows Server 2003-based servers can authenticate users who connect from computers that are running all earlier versions of Windows. However, versions of Windows earlier than Windows 2000 do not use Kerberos for authentication. For backward compatibility, Windows 2000 and Windows Server 2003 support LAN Manager (LM) authentication, Windows NT (NTLM) authentication, and NTLM version 2 (NTLMv2) authentication. The NTLM, NTLMv2, and Kerberos all use the NT hash, also known as the Unicode hash. The LM authentication protocol uses the LM hash.
   
   -----
   
   Yes, you do use 128-bit RC4 (with the option for DES) for symmetric encryption (NOT password hash) of kerb tickets.  A ticket can be obtained by anyone who knows the pass phrase that results in the same NT hash.  As stated in MS KB299656, Kerb for 2003 uses NT hash (which is MD4, not RC4).  You do not use RC4 *instead of* MD4, you use RC4 directly *in addition* to indirect use of MD4.  As soon as you accept a kerb ticket assigned by a 2003 server, you have also indirectly accepted the MD4 verification system of the password so the user could get the kerb ticket in the first place.  I am not consern with the RC4 symmetric encryption algorthim used after initial password verification has completed since this is not the weak link of the security model.  I am consern with the hash algorthims that are stored and used for verification of the password.  As stated by MS KB299656, if you are using 2003 as the ticket server, you are indirectly using NT hash.  Your avoiding addressing this fact and simply pointing out what ticket system has a different symmetric encryption.  However, the fact still remains that once someone that had administrative rights to the X.500 directory is able to conduct an unauthorized password audit, they can easily get assigned tickets to accounts they shouldn't have access to and use of RC4 (or even 256 bit symmetric encryption) won't matter.
   

   posted at 06:14PM 06/09/2006
9. fluke said:

   My last issue seems to have been gone unanswered.  The level of comfort I have with MS-AD as the kerberos ticket server has not been improved,  It still seems that in any enviroment where a disgruntled administrator could be a factor that MS-Kerb creates an additional unwarrented security weakness.
   
   I would like to ask instead the following:
   
   - What problems need to be addressed to use *nix as the ticket server for an AD enviroment?
   
   - Is there an open standard documentation on the key rotation method used in AD that was discussed during one of the Centrify talks?  Is this planned to be part of the future kerberos standard or will it remain a MS prioritary extention to the kerb enviroment?
   
   - The original development of Kerberos seems to have been to strictly provide an authentication system.  Why does AD seem to use a reserved field to extend Kerberos tickets to also be an authorization system?  Why isn't LDAP used to provide all authorization attributes?
   
   - Has Microsoft's move towards promoting interoperatablity changed the terms of use regarding documentation describing the modifications to the kerberos ticket system?
   
   Thanks
   
   

   posted at 03:52PM 06/20/2006
10. pmoore said:

    Fluke,

    Sorry to have left this dangling. I dont really know what to say, every kerberso ticket server needs to store the password of the user or the hashes derived from it - otherwise they cannot encrypt the tickets. Microsoft's implementation does not store the hash in the LDAP accessible part of AD; it is not obtainable over the wire, and there are no APIs to read it for code running ont the box. Ultimately somebody with unrestricted access to the domain controller could find the hashes, but they have total control in this case anyway - they can reset passwords add new accounts etc. This is true of unix KDCs too.

    Regarding the password rotation. this is not a kerberos extension - it is a plugin to the password change mechanism that gets trigger regardless of how the change is requested. The mechanism for doing that is published by microsoft and they include sample code for users to write their own (and many do)

    Microsoft uses a field in the kerberos ticket call 'authorization data' it was added by the MIT kerberos designers specifically to allow extensions that handle authorization (becuase MIT did not feel that they could specify it but knew that it would be useful to provide the extension point) - see section 5.2 of rfc1510

    The PAC (the microsoft supplied authorization data) is no longer restricted (I beleive this is what you are referring to)

    Note this is Paul Moore (centrify) not Microsoft responding.  

    posted at 04:48PM 08/01/2006

• 1
• 2
• Next >