Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

sarra — Mon, 29 Jun 2009 10:34:54 GMT

je veux installer media player

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

sammy — Sat, 04 Apr 2009 19:15:37 GMT

Y29K78 vkoo7wvY5Xkfak7bf1Th

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

reda — Sat, 01 Nov 2008 21:55:35 GMT

kbhjdhjbvdesvjhqdvjguyzejk,l;mmmmmmmmmmmmmgfvc

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

robby — Tue, 14 Oct 2008 00:18:23 GMT

UykGUa ghs85n1gdGnbZ95Iis3f

Centrify's Paul Moore Fields Questions from the Community

Port 25 — Thu, 19 Oct 2006 18:57:23 GMT

Paul Moore sits down with Sam in this podcast, our second go around with Centrify. For those who don't know, Centrify builds software that provides access control and centralized identity management in mixed networks (yes, this can include Windows, Linux,

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

pmoore — Wed, 13 Sep 2006 00:21:09 GMT

Dmitri,

(Sorry for the long delay)

Yes we create kerberos tickets and these tickets can be used to access domain resources just like they can in a windows environment. Examples of this are file shares, LDAP access, HTTP auth, etc. Its really a very nice user experience

The tickets are stoed in a cache file that belongs to the user under /tmp

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

dmcneely — Thu, 10 Aug 2006 16:28:16 GMT

Dmitri, thanks for your interest, you've asked good questions about Kerberos and what happens after the user logs in. DirectControl authenticates the user to Active Directory, communicating with the nearest available Domain Controller based on Site information (Site aware). Once the user credentials have been validated by the domain controller, a Kerberos TGT is retrieved and a Kerberos Service Ticket for the Unix host the user is logging into as well as the user’s Unix account profile which is managed within the Zone which the computer is a member. The TGT can then be used by the MIT Kerberos infrastructure that DirectControl installs and manages in order to provide SSO to other services that the user accesses. The Kerberos tickets are stored in a ticket cache which is located in the tmp directory where the file for each user is owned by that user. These files are also encrypted using Kerberos functions so that the tickets are not vulnerable. Applications that are configured to make calls to GSSAPI or to use the Kerberos libraries that DirectControl supplies will be able to ask for a Kerberos Ticket for a remote system or service, thus providing the user with Single Sign-On to that service. An example is the use of OpenSSH, which Centrify makes available pre-compiled with support for Kerberos. The OpenSSH client will negotiate with the remote host to determine how to authenticate and if the remote host OpenSSH Server supports Kerberos, then the client will ask the Kerberos libraries for a Service Ticket for the remote host, at this point the Kerberos infrastructure on the client workstation will use the TGT to request a Service Ticket for the remote host which the Domain Controller will provide if the remote host has a computer account in Active Directory, at this point the OpenSSH client will have a Service Ticket for the remote computer which can be presented to validate who the local user is and enable the user to gain access to the remote host if the user is authorized to gain access to the remote host. This same Kerberos negotiation can also be used to authenticate a user to a remote Apache (or Tomcat, WebLogic, WebSphere) web server running on Unix where the DirectControl agent is installed for the Operating System and the Web Server. This will enable SPNEGO to work correctly for users logging into Windows computers or Unix systems that have have DirectControl installed, such as my MacBook Pro running either Safari or Firefox. As you can see, one of the real values of integrating with Active Directory is that it is now possible to provision a user and manage his authentication credentials in one place (for password or smart card logins) and provide authentication services across the entire heterogeneous enterprise. -David Director of Product Management Centrify

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

Dmitri Pal — Tue, 08 Aug 2006 13:50:44 GMT

Thank you for the presentation. Very helpful. However it does not talk about the other important piece of the puzzle. Now as the UNIX machine and user are a part of Windows domain how they access file shares and other domain resources. As far as I understand as a result of the user kerberos authentication user should have got a kerberos ticket. This ticket in Windows world used for the SSO inside the domain. Each time user tries to access something this ticket is presented to DC and verified (I know it is more complex but still...). So questions: 1) Is the ticket created in this case too? 2) Where is it stored? 3) How the SSO works and does it actually work? Thanks

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

pmoore — Tue, 01 Aug 2006 21:48:58 GMT

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.

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

fluke — Tue, 20 Jun 2006 20:52:31 GMT

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

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

fluke — Fri, 09 Jun 2006 23:14:35 GMT

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.

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

pmoore — Fri, 09 Jun 2006 19:31:21 GMT

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.

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

fluke — Thu, 08 Jun 2006 19:32:18 GMT

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.

Paul Moore Interview Part 2 - Call for Questions

Sam Ramji — Thu, 25 May 2006 04:50:16 GMT

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

re: Tom Kemp & Paul Moore: Integrating Linux, UNIX and Windows with Centrify

pmoore — Wed, 17 May 2006 09:26:55 GMT

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)