ну а толку то от софтины, ну будет она работать и что? Гибкость виндового кербероса в том, что его использует виндовая GINA - graphical identification and authentication. И ни с каким другим кроме виндового керберосом она работать не может. Причина заключается в том, что мелкософт в реализацию кербероса от MIT внёс некоторые изменения:
Из книги Linux in a Windows world
9.1.4. Windows and Kerberos
In theory, Windows can fit into a Kerberos realm as easily as Linux. In practice, of course, you'll need to learn to configure both Linux and Windows; configuration file locations and the like will differ between the two platforms. You might also run into compatibility problems related to specific Kerberos implementations.
Of particular note along these lines is the fact that Windows 2000 and later ship with AD support, and AD includes Kerberos as one of its components. Microsoft, however, implemented Kerberos in a slightly different way than did other providers. Some notable areas of divergence include:
Encryption algorithms
For political and technical reasons, Microsoft chose to support a different set of encryption algorithms than did the versions of Kerberos available in 2000. The practical upshot of this decision is that, if you use an AD controller as your KDC, you must either enable Data Encryption Standard (DES) encryption on the KDC and change users' passwords or use a recent version of Kerberos (such as MIT Kerberos 1.3 or later) on the non-Microsoft systems.
The PAC
Perhaps the biggest Windows/non-Windows Kerberos compatibility issue is the Privilege Access Certificate (PAC). This is an extra field added to tickets returned by a Windows KDC. Microsoft's own Windows clients typically refuse to work with a KDC that doesn't return a PAC, which makes interoperating with a Linux KDC difficult, for example. Microsoft developed the PAC in a proprietary way, but in late 2003 some documentation on the PAC became available, so this problem is also fading in importance. Fortunately, non-Microsoft Kerberos implementations typically ignore the PAC, so Linux Kerberos application servers and clients should be able to operate with a Windows KDC.
Cached credentials
Windows systems cache their login credentials as a way of supporting logins on laptops or in case of a KDC or network failure. Ordinarily, this practice poses no problems, but if a user logs on using a cached credential and a non-Microsoft KDC then becomes available, the system isn't likely to notice the KDC, resulting in an inability to access network resources.
Overall, using Microsoft's own KDC as your network's KDC in conjunction with Linux application servers and clients works well. If you're using older Kerberos implementations, though, you may need to enable DES support and then change users' passwords so that the new password is encoded in DES form. This step shouldn't be necessary with recent Kerberos V5 implementations for Linux, though. (If in doubt, check whether the Kerberos implementation supports the RC4-HMAC encryption algorithm.) For the most part, the details of administering a Windows KDC are beyond the scope of this book.
Using Windows clients with a non-Microsoft KDC is a bit trickier, but it is possible. You must create local Windows accounts on the Windows system for your users and use special tools to configure Windows to use the KDC for authentication. This process is described later in this chapter, in Section 9.5.3. Alternatively, you can install a non-Microsoft Kerberos package and run it without using Kerberos for logon authentication. Instead, you'd use regular Kerberized clients and servers under Windows, much as you would their equivalents under Linux.
Вот ещё инфа из рассылок кербероса:
http://mailman.mit.edu/pipermail/kerber ... 01796.html
Just for the record, a Windows 2000 client will send some preauth data
requesting that the PAC be included (this is described in John Brezak's
IETF draft specifying the PAC format). That may be what was being
referred to in previous mails. The default is to include the PAC,
but it might be sensible for a UNIX-based KDC to make the default
to not include the PAC.
Adding support to a KDC for the PAC is not that difficult if you have
a sensible architecture (for example, an integrated directory backend
for the KDC). The difficulty lies in some of the other, unpublished,
protocols which are necessary to domain logon.
и
http://mailman.mit.edu/pipermail/kerber ... 07214.html
On Thu, 10 Feb 2005 23:20:37 -0500, Fredrik Tolf wrote:
> I have to admit that I don't know a lot about Windows and Kerberos.
> However, as I've understood it, the only thing that really prevents you
> from using a MIT KDC for Windows clients is the authorization data they
> ship in the ticket, right? And this is called "PAC", right?
The necessary information about the PAC structure is freely available
on MS' website [1] (and contrary to popular belief the use of the
authorization-data field is as designed and not a case of "embrace
and extend").
The problem is what is *in* the PAC. It contains the principal's group
membership list which is required to create the "token" used by Windows
clients to make access control decisions.
Group information in a MS forest is stored in Active Directory, on each
domain controller, and depending on the group type, may be replicated
between AD and domain controllers (AD and MS Kerberos are very tightly
coupled). The groups for a particular authentication are expanded as
the client traverses the trust to the target [2].
So to use an alternate Kerberos implementation you would need to implement
a variety of MS specific communication [2] to properly and efficiently
produce the necessary group SIDs to construct the PAC. The closest thing
that comes to this is probably XAD [4] which is an amalgamation of Samba,
OpenLDAP, MIT Kerberos, and proprietary stuff but I have no idea how
well it works as I have never used it.
Mike
[1]
http://msdn.microsoft.com/library/defau ... dn_pac.asp
[2]
http://pluralsight.com/wiki/default.asp ... Group.html
[3] I have recently writen an Open Source MIDL compatible IDL
compiler that could be used to generate the necessary DCE RPC
proxies for much of this communication. It can be located at
http://jcifs.sam ba.org/src/midlc-<version>.tar.gz
[4]
http://www.padl.com/Products/XAD.html
Коротко перевожу:
в виндовой реализации есть такое доплнительное поле PAC. Реализовать его просто, т.к. микрософт открыла на него спецификацию. Но инфа передаваемая в этом поле зависит от кучи проприетарных виндовых протоколов, на которых спецификации нет. В результате чего виндовый клиент не сможет работать ни с каким другим керберосом кроме как виндовым. Парни из самбы походу подглядели как реализовать эту фичу, поэтому ждём 4 самбы.
Кстати, по моим скромным прогнозам ожидать её стоит уже в 2010 году, как минимум бэту. Прогноз мой строится на основе чтения оф. вики и расылок самбы. Ещё в 2010 году должна выйти книга The Definitive Guide to Samba 4, от O'Relly, думаю они тоже делают такой прогноз
