From: "Bryan J. Smith b.j.smith@ieee.org"
So? I've been authenticating Samba against NIS servers since the mid-'90s ... You can even use pGINA to replace your NT/200x/XP login to authenticate against other servers ... If you are the former, you _can_ switch _away_ from CIFS altogether! Samba will _never_ reverse engineer all of Microsoft's LDAP schema ... You really need an independent architect to come in and make your life easier. Because it seems your department isn't aware of all your interoperability options.
I want to point out one thing. Understand Samba is a collection of services designed of and for CIFS/SMB. It is _not_ a complete "enterprise directory solution."
Samba includes: - A Legacy Registry-SAM compatible password store - A Legacy NetBIOS-WINS naming service and protocol - A Legacy NTLM (NT LAN Manager) authentication protocol
And then "wraps into" traditional UNIX services like UNIX resolver (DNS, NIS, NSSwitch, etc...), UNIX authentication (files, NIS, PAM, LDAP, etc...), etc...
Newer versions of Samba 2.2 include: - MS ADS subset schema for LDAP (OpenLDAP often used)
And Samba 3.0 also introduces: - SASL authentication with Kerberos stores (either MS ADS Kerberos or a MS'ized UNIX Kerberos client/KDC services).
Samba strives to be a "drop in replacement" for a native Windows DC and file server, including naming (browser) and authentication.
But you do _not_ have to use Windows-centric naming or authentication. You can build a network where you either are UNIX/Linux NsDS/OpenLDAP "tree'd" with or without Kerberos, possibly authenticating against native MS ADS DCs or even Samba emulating ADS DCs, or maybe using pGINA on the clients, or you can even have a completely segmented NsDS/OpenLDAP tree/network from native MS ADS network, and use some synchronization between the two.
Samba itself is definitely _not_ a UNIX client designed service. And even if you have native MS ADS deployed, you should be running services on the DCs to present UNIX-like interfaces for authentication, naming, etc... on the server, not trying adhoc, manual, kludge in things. And if you're old MS CIFS/PDC, get off of it. Get your network to NsDS (now Red Hat Directory Server) before it's too late -- even if just for your UNIX portion. Or at least introduce 23+ year-old NIS for things.
Golden Rule: The _client_ is always right.
Always present the _native_ interfaces of the client OS from a server when it comes to: 1) naming 2) directory/store 3) authentication 4) file services
Whether you are a true UNIX, e.g., DNS/NIS, NIS, hash, NFS (NIS) DNS/NIS, NIS, Kerberos, NFS (NIS-Kerberos) NIS+, NIS+, RSA, NFS (NIS+) DNS, LDAP, RSA, NFS (Sun One) DNS, LDAP, hash, NFS (LDAP) DNS, LDAP, SASL/Kerberos, NFS (LDAP-SASL/Kerberos)
Or maybe a Windows, e.g., NetBIOS/WINS, SAM, NTLM, SMB (CIFS) DNS, MS LDAP, MS Kerberos, SMB (ADS)
Or maybe even a Novell, e.g., SAP, Bindery, hash/RSA, NCP (Bindery) NLSP, X.500/DAP, RSA, NCP (NDS aka eDirectory)
You should interface with your clients with what _they_ expect, not what your "back-end" is by default.
-- Bryan J. Smith mailto:b.j.smith@ieee.org
But you do _not_ have to use Windows-centric naming or authentication. You can build a network where you either are UNIX/Linux NsDS/OpenLDAP "tree'd" with or without Kerberos, possibly authenticating against native MS ADS DCs or even Samba emulating ADS DCs, or maybe using
Are you saying that Samba can emulate ADS DCs?
On Sun, 2005-07-17 at 22:03 +0800, Feizhou wrote:
Are you saying that Samba can emulate ADS DCs?
Yes and no.
Yes, Samba 3.0 can provide ADS DC functionality such as: - Authentication (including full MS Kerberos as KDC**) - Naming (DNS SysRecs, NetBIOS/WINS, etc...) - Basic ADS Schema for DCs in LDAP
This includes: - Samba 3.0 being a "member server" to native Windows DCs
[ **NOTE: IIRC, Microsoft's Kerberos can one-way trust to UNIX Kerberos Realms without issue. But going the opposite way, that's where the MS Kerberos modifications were required. Hence how Samba 3.0 can be a member server in a native Windows DC ADS setup, or even completely emulate the ADS DC authentication facilities in the absence of any Windows DCs and it controls the ADS network. ]
But no, Samba 3.0 cannot: - Handle extensive, ADS-centric Schema (e.g., Exchange) and interfaces - Be a DC to other, native Windows DCs
These are likely _never_ to happen (especially the first one).
Bryan J. Smith wrote:
On Sun, 2005-07-17 at 22:03 +0800, Feizhou wrote:
Are you saying that Samba can emulate ADS DCs?
Yes and no.
Yes, Samba 3.0 can provide ADS DC functionality such as:
- Authentication (including full MS Kerberos as KDC**)
What is this KDC**?
- Basic ADS Schema for DCs in LDAP
This includes:
- Samba 3.0 being a "member server" to native Windows DCs
[ **NOTE: IIRC, Microsoft's Kerberos can one-way trust to UNIX Kerberos Realms without issue. But going the opposite way, that's where the MS Kerberos modifications were required. Hence how Samba 3.0 can be a member server in a native Windows DC ADS setup, or even completely emulate the ADS DC authentication facilities in the absence of any Windows DCs and it controls the ADS network. ]
But no, Samba 3.0 cannot:
- Handle extensive, ADS-centric Schema (e.g., Exchange) and interfaces
- Be a DC to other, native Windows DCs
Are you then saying that we can get a Samba 3.0 box to be an ADS DC for Windows 2000/XP workstations?
On Sun, 2005-07-17 at 22:20 +0800, Feizhou wrote:
What is this KDC**?
Key Distribution Center (KDC) aka "the key server" for Kerberos.
It is the server that must be the most secure on your network. My #1 problem with MS ADS is that the KDC is also a RPC server offering other services, hence hackable, hence a _bad_ idea for a KDC.
Before you attempt to understand UNIX/Linux and Windows interoperability, you should _really_ read up on what ADS is really is: DNS naming + MS defined schema LDAP store + MS modified Kerberos authentication
In reality, it's only the MS defined schema, and the interfaces around that schema, that are the issue. But more on that in a moment.
Are you then saying that we can get a Samba 3.0 box to be an ADS DC for Windows 2000/XP workstations?
First off, again, Samba is _not_ the "only option" for Windows. Samba started off as just the Server Message Block (SMB) file protocol. The other interfaces that have built around it are just for support, but they are _not_ required if you know how to deploy a set of enterprise services.
So, yes, Samba 3.0 with MS modified Kerberos can emulate all the authentication needs of Windows 2000/XP clients, while its SMB service provides the file services. It also has its own, basic LDAP schema, some of which that can support part of the hierarchial nature of ADS, along with DNS services -- to a point.
But, if you don't use the default GINA in Windows 2000/XP in the first place, then you don't need to emulate Microsoft's protocols for authentication. By replacing it with Pluggable GINA (pGINA), you can authenticate Windows 2000/XP against whatever you want. This can be Kerberos, but it doesn't have to be -- it can be legacy NTLMv2**.
Then when you provide Samba SMB network file services to Windows 2000/XP clients, you can complete the authentication/authorization how you wish. If you want to use local authentication -- possibly because all your Samba servers are in the Kerberos realm as well, or maybe you're even using a legacy password store like TDB that is distributed -- then do ahead! Samba doesn't have to provide anything other than the SMB network file service, you can leave everything else to _other_, _native_ services.
People don't seem to separate this fact. They think they need Samba to do everything. In reality, all Samba has to do is provide the SMB network file services, and maybe some added LDAP schema and interfaces for a few services, or maybe a few legacy interfaces (NTLM, NetBIOS/WINS, etc...). Everything else can be another solution -- including DNS, the Kerberos KDC (which Samba may or may not use directly, it may use "local authentication" because the individual Samba file servers are already Kerberos clients), direct LDAP schema and services, etc...
The key is breaking down what ADS is, what Samba provides, and what you can do with UNIX and _replacements_ for Windows clients -- e.g., pGINA. pGINA was largely developed by Bynari, who typically works with IBM Global Services on providing 10,000+ node _enterprise_ networks with reliable collaboration systems. I.e., networks that don't easily do well with Microsoft ADS-centric services.
That's what "architects" do. They don't work with "products," they work with "technologies." Even Exchange is quite limited (largely a _client_-side collaboration solution) and many open solutions more capable (e.g., _true_ "server-side" collaboration solutions).
**NOTE: Ironically, many legacy client services in Windows 2000/XP _still_ rely on legacy NetBIOS/Windows and at least NTLMv2 authentication for various capabilities. You can't turn them off without breaking a lot, hence why it's not difficult for Samba 3.0 servers to be "member servers." In a nutshell, even ADS "Native Mode" is _not_ really "native" -- because Windows clients still use a _lot_ of legacy services. The Samba technology-specific docs are very good in explaining these "limitations" in Microsoft's enterprise design, especially the client issues when you disable "legacy" things.
Bryan J. Smith wrote:
On Sun, 2005-07-17 at 22:20 +0800, Feizhou wrote:
What is this KDC**?
Key Distribution Center (KDC) aka "the key server" for Kerberos.
It is the server that must be the most secure on your network. My #1 problem with MS ADS is that the KDC is also a RPC server offering other services, hence hackable, hence a _bad_ idea for a KDC.
Before you attempt to understand UNIX/Linux and Windows interoperability, you should _really_ read up on what ADS is really is: DNS naming
- MS defined schema LDAP store
- MS modified Kerberos authentication
Yes, I was wondering whether you were trying to say that Samba could do the extra cruff MS threw into their Kerberos/LDAP/DNS thingamich.
In reality, it's only the MS defined schema, and the interfaces around that schema, that are the issue. But more on that in a moment.
Are you then saying that we can get a Samba 3.0 box to be an ADS DC for Windows 2000/XP workstations?
First off, again, Samba is _not_ the "only option" for Windows. Samba started off as just the Server Message Block (SMB) file protocol. The other interfaces that have built around it are just for support, but they are _not_ required if you know how to deploy a set of enterprise services.
So, yes, Samba 3.0 with MS modified Kerberos can emulate all the
So not Samba 3.0 + non-MS Kerberos + non-MS LDAP but Samba directing all to an ADS DC.
authentication needs of Windows 2000/XP clients, while its SMB service provides the file services. It also has its own, basic LDAP schema, some of which that can support part of the hierarchial nature of ADS, along with DNS services -- to a point.
But, if you don't use the default GINA in Windows 2000/XP in the first place, then you don't need to emulate Microsoft's protocols for authentication. By replacing it with Pluggable GINA (pGINA), you can authenticate Windows 2000/XP against whatever you want. This can be Kerberos, but it doesn't have to be -- it can be legacy NTLMv2**.
Then when you provide Samba SMB network file services to Windows 2000/XP clients, you can complete the authentication/authorization how you wish. If you want to use local authentication -- possibly because all your Samba servers are in the Kerberos realm as well, or maybe you're even using a legacy password store like TDB that is distributed -- then do ahead! Samba doesn't have to provide anything other than the SMB network file service, you can leave everything else to _other_, _native_ services.
People don't seem to separate this fact. They think they need Samba to do everything. In reality, all Samba has to do is provide the SMB network file services, and maybe some added LDAP schema and interfaces for a few services, or maybe a few legacy interfaces (NTLM, NetBIOS/WINS, etc...). Everything else can be another solution -- including DNS, the Kerberos KDC (which Samba may or may not use directly, it may use "local authentication" because the individual Samba file servers are already Kerberos clients), direct LDAP schema and services, etc...
The key is breaking down what ADS is, what Samba provides, and what you can do with UNIX and _replacements_ for Windows clients -- e.g., pGINA. pGINA was largely developed by Bynari, who typically works with IBM Global Services on providing 10,000+ node _enterprise_ networks with reliable collaboration systems. I.e., networks that don't easily do well with Microsoft ADS-centric services.
That's what "architects" do. They don't work with "products," they work with "technologies." Even Exchange is quite limited (largely a _client_-side collaboration solution) and many open solutions more capable (e.g., _true_ "server-side" collaboration solutions).
**NOTE: Ironically, many legacy client services in Windows 2000/XP _still_ rely on legacy NetBIOS/Windows and at least NTLMv2 authentication for various capabilities. You can't turn them off without breaking a lot, hence why it's not difficult for Samba 3.0 servers to be "member servers." In a nutshell, even ADS "Native Mode" is _not_ really "native" -- because Windows clients still use a _lot_ of legacy services. The Samba technology-specific docs are very good in explaining these "limitations" in Microsoft's enterprise design, especially the client issues when you disable "legacy" things.
:) So how do you provide a non-MS Kerberos single login for Windows 2000/XP clients where the user account management is centralized?
On Sun, 2005-07-17 at 09:13 -0500, Bryan J. Smith wrote:
But no, Samba 3.0 cannot:
- Handle extensive, ADS-centric Schema (e.g., Exchange) and interfaces
- Be a DC to other, native Windows DCs
These are likely _never_ to happen (especially the first one).
But the good news with Samba 3.0 is that it _can_: - Be a BDC or PDC to native Windows NT 4.0 PDC or BDCs - Completely emulate all CIFS/PDC functionality
In other words, you can replace _all_ NT 4.0 PDCs and/or BDCs with Samba 3.0. You can even put in a Samba 3.0 instance as a BDCs, then promote it as a PDC with virtually no issue -- getting rid of any NT 4.0 requirement on your network.
You can then enable the ADS functionality, and have a network that looks like an ADS domain from the Windows clients and even native Windows member servers.
But no, it won't work with Windows services that extend the schema (e.g., Exchange) and not, it won't replicate with native Windows DCs.
How you address that -- either making your UNIX network native Windows ADS' bitch, or segment the UNIX and Windows networks, and use facilities to synchronize passwords, schema, etc... (be they free or various commercial utilities) -- is up to you.
But Samba on its own is _not_ an "enterprise directory solution." It is just the facility by which various Windows interfaces and services are supported. Even it still relies on external LDAP and Kerberos mechanisms for schemas/store and authentication/store, and you should remember that those LDAP and Kerberos mechanisms can be used for _real_ UNIX capabilities outside of just Samba. E.g., there are ways to store various, former NIS maps in LDAP (such as NFS automounter maps), as well as authentication UNIX systems _directly_ with Kerberos.
Sometimes people get so focused on Samba, and using 2nd or even 3rd compounded services upon compounded services through Samba -- they forget to use the native UNIX service. E.g., authenticating UNIX/Linux users with NTLM, instead of just using Kerberos.
Bryan J. Smith wrote:
On Sun, 2005-07-17 at 09:13 -0500, Bryan J. Smith wrote:
But no, Samba 3.0 cannot:
- Handle extensive, ADS-centric Schema (e.g., Exchange) and interfaces
- Be a DC to other, native Windows DCs
These are likely _never_ to happen (especially the first one).
You can then enable the ADS functionality, and have a network that looks like an ADS domain from the Windows clients and even native Windows member servers.
But no, it won't work with Windows services that extend the schema (e.g., Exchange) and not, it won't replicate with native Windows DCs.
Since when did Samba manage to pull off become an ADS DC for Windows 2000/XP workstations?
On Sun, 2005-07-17 at 22:29 +0800, Feizhou wrote:
Since when did Samba manage to pull off become an ADS DC for Windows 2000/XP workstations?
At this point, you're hopelessly lost. I can keep talking about it, but you won't get it until you have some "technical background."
First off, read up on Samba 3.0. It is a set of "technologies" for Windows interoperability. To emulate an ADS DC, you have to add LDAP and MS Kerberos into the mix. It _only_ emulates it to a point.
At the _same_time_, read up on these "technologies" ...
1. Naming Services: DNS, UNIX resolver, DNS, Windows resolver modes, NetBIOS, WINS, SAP, NLSP
2. Network Authentication: NT Security Accounts Manager (SAM), NT/LAN Manager (NTLM), NTLMv2, RSA, DH/DSS Kerberos, MS Kerberos
3. Directory Services: X.500 DAP, LDAP, Common UNIX Schema, Common Windows Schema
4. File Services: NFSv2, NFSv3, NFSv4, SMB (various, incompatible versions), NCP, AFS
Once you have a "grasp" on the "technologies", you can understand how: - MS CIFS (NetBIOS/WINS, network-SAM, NTLM, SMB) - MS ADS (DNS, LDAP-SAM, MS Kerberos, SMB) - Novell Bindery (SAP, Bindery, RSA, NCP) - Novell NDS aka "eDirectory" (NLSP/DNS, X.500 DAP, RSA, NCP) - Sun NIS (UNIX resolver, flat-maps, UNIX local, NFS) - Sun NIS+ (UNIX resolver, DAP-like, RSA, NFS) - Sun One (DNS, LDAP, RSA, NFS)
_Everything_ is _always_ "piecemeal" in a network. CIFS, ADS, Bindery, NDS, Sun One, etc... just presents everything as "integrated."
A. And also read up on client modifications like: - pGINA (replacement NT/200x/XP Graphical Login) - NSSwitch (Linux, Solaris, others) - PAM (Linux, Solaris, others)
You can use different client/server solutions in different networks, _regardless_ of what the "real backend" may be.
The only "big issue" is what Microsoft is doing with ADS. MS is purposely tying its services to its own MS LDAP schema and interfaces into that schema, in order to make all networks completely reliant on its own, native ADS. This will be a "moving target" for Samba.
The key is to _not_ adopt MS services that require those ADS-only schema and interfaces -- e.g., MS Exchange, MS SQL Server, etc... Enterprise with 10,000+ nodes do _not_ because they do not scale. In the worst case, they limit their exposure to them -- "regionalize" or "departmentalize" their deployment.
On Sun, 2005-07-17 at 09:54 -0500, Bryan J. Smith wrote:
At this point, you're hopelessly lost. I can keep talking about it, but you won't get it until you have some "technical background."
I hope you don't take that as an insult (I know you will though). You didn't know what a KDC is, so you aren't familiar with how ADS works, which is a _core_component_ to Samba 3.0's functionality.
Microsoft is the "king of buy/reuse/non-development," and ADS is little more than the NT SAM stored with LDAP, with a sprawling amount of (poorly designed IMHO) schema with MS-centric Kerberos for authentication. Microsoft was under contractual obligation with MIT to disclose their Kerberos modifications, and even then they sat on it for 2 years, but that it is now well documented and other interfaces reverse engineered from it. The kicker is the sprawling MS LDAP schema, and the interfaces used on the Windows side -- that's a "moving target" reverse engineering issue that will probably _never_ be fully supported.
Now I'm going to take the rest of the day and enjoy my wife, hence why I won't follow-up on any more questions. If anyone needs me for further discussion that is clearly getting "OT" for this list, you can contact me off-list or, better yet, hire me as an independent architect for your organization. ;->
Bryan J. Smith wrote:
On Sun, 2005-07-17 at 09:54 -0500, Bryan J. Smith wrote:
At this point, you're hopelessly lost. I can keep talking about it, but you won't get it until you have some "technical background."
I hope you don't take that as an insult (I know you will though). You didn't know what a KDC is, so you aren't familiar with how ADS works, which is a _core_component_ to Samba 3.0's functionality.
I know what a Kerberos authentication system is. You mean a core component in Samba 3.0's functionality as an ADS client.
Microsoft is the "king of buy/reuse/non-development," and ADS is little more than the NT SAM stored with LDAP, with a sprawling amount of (poorly designed IMHO) schema with MS-centric Kerberos for authentication. Microsoft was under contractual obligation with MIT to disclose their Kerberos modifications, and even then they sat on it for 2 years, but that it is now well documented and other interfaces reverse engineered from it. The kicker is the sprawling MS LDAP schema, and the interfaces used on the Windows side -- that's a "moving target" reverse engineering issue that will probably _never_ be fully supported.
Now that is news to me.
Now I'm going to take the rest of the day and enjoy my wife, hence why I won't follow-up on any more questions. If anyone needs me for further discussion that is clearly getting "OT" for this list, you can contact me off-list or, better yet, hire me as an independent architect for your organization. ;->
:)
Bryan J. Smith wrote:
On Sun, 2005-07-17 at 22:29 +0800, Feizhou wrote:
Since when did Samba manage to pull off become an ADS DC for Windows 2000/XP workstations?
At this point, you're hopelessly lost. I can keep talking about it, but you won't get it until you have some "technical background."
You assume too much and you are not clear enough in what you post.
First off, read up on Samba 3.0. It is a set of "technologies" for Windows interoperability. To emulate an ADS DC, you have to add LDAP and MS Kerberos into the mix. It _only_ emulates it to a point.
Geez....I've been trying to get whether you are saying there was a way to do the whole ADS DC thing without a MS-Kerberos in the mix.
The only "big issue" is what Microsoft is doing with ADS. MS is purposely tying its services to its own MS LDAP schema and interfaces into that schema, in order to make all networks completely reliant on its own, native ADS. This will be a "moving target" for Samba.
The key is to _not_ adopt MS services that require those ADS-only schema and interfaces -- e.g., MS Exchange, MS SQL Server, etc... Enterprise with 10,000+ nodes do _not_ because they do not scale. In the worst case, they limit their exposure to them -- "regionalize" or "departmentalize" their deployment.
How do you get centralized user account management without MS Kerberos?
-
Bryan J. Smith -
Bryan J. Smith <b.j.smith＠ieee.org> -
Feizhou