Re: Samba PDC/BDC
On 1/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -- Original message --From: Paul Lussier [EMAIL PROTECTED] Ben Scott [EMAIL PROTECTED] writes: Okay, but what does any of that Heimdal/Kerberos stuff have to do with authenticating NTLM clients? Nothing, but he keeps talking about AD authentication, which Kerberos *would* be a component of if it would work.And at one point, there was a more generic single-sign on discussion which included this as well, but has since gotten lost in the noise.My question was originally Can I have a Samba server over there act as a PDC for them using the same Windows Domain. That question came about because it was brought to my attention that there will be traveling between here and there quite often, and re-configuring their laptops for a different windows domain is a PITA.But, for those of you just joining the thread, the answer so far is:1) Yes, you can do that.2) No, you can't do that.3) You might be able to do that, but only if you do something completely different then what you originally wanted to do. You can only do that with samba4, which isn't even alpha code yet. Only samba 4 allows you to join an Active Domain as a domain controller. I was mistaken in believing that samba 3 could hndle it, as samba 3 can only AUTH against an Active Directory, but not serve as the domain controller. Thomas
Re: Samba PDC/BDC
On 1/16/06, Bill McGonigle [EMAIL PROTECTED] wrote: I read that as saying, in order to be an AD DC, Samba would have to have all the functionality it has now, plus all the functionality of an LDAP server, plus all the functionality of a Kerberos server. We have all those parts. It's unix. We link libraries. :) Ah, yes, of course, all you need to integrate functionality is a linker... *rueful grin* -- Ben cat `which slapd` `which smbd` `which krb5kdc` ActiveDirectoryd Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Bill McGonigle [EMAIL PROTECTED] writes: On Jan 16, 2006, at 11:26, Paul Lussier wrote: Windows clients can not do resolution against one entity (LDAP) and authentication against another (Kerberos) *unless* it's against Active Directory. AD does use LDAP and Kerberos for most of its heavy lifting. Do we know what the missing magic pixie dust is to tie this together? Yes, the proprietary extensions to Kerberos that MS added. Also, it is incorrect to claim that AD uses LDAP and Kerberos. AD is *based* on LDAP, Kerberos, and several other components, like DHCP and DNS. AD is an all-encompassing Directory Services server, and you can turn off certain components like DNS or DHCP. However, an AD server wants to be it's own DNS server, in it's own domain, etc. A Windows client resolves queries and authenticates against an AD system *NOT* using the standard LDAP or Kerberos protocols, but rather a special, proprietary protocol. Therefore, a windows client uses LDAP and Kerberos together only when directed towards an AD server and has no way of knowing how to separate the LDAP query from the Kerberos authentication query. As far as the Windwos client is concered, there is on an AD query which may or may not include an LDAP, Kerberos, DNS, or DHCP component. Samba can not authenticate against Kerberos. Doesn't winbind accomplish this? No, WinBind, from: http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html states that it does exactly the opposite of what is desired here. It allows a random UNIX box to authenticate against a Windows NT domain controller. I guess, if you wanted all your account management in one place, and you didn't mind the management of said accounts being done on a Windows system, then *might* get you the Holy Grail of single sign-on. My dream is to ultimately have Windows be just another OS in an environment which is managed from a central UNIX environment. I can already do this with all variants of UNIX/Linux, and MacOS. Windows is the last hold out (as usual). Unfortunately, until MS either decides it's in their best interests to allow us to do what we want, or someone reverse-engineers AD queries, we're stuck. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Thomas Charron [EMAIL PROTECTED] writes: True, however, it would seem Kenny seems to intend to not require any auth traffic to have to go over the wire to the remote site. So in reality, when authenticating via LDAP, he'd want to replicate the LDAP server is TWO locations. Not so! You have an LDAP server in both locations, both of which are children of the ou=corp,ou=foo,ou=bar domain and allow *any member* of that super-domain access. You manage the accounts for these domains centrally on the super-domain server, and occassionally push out the entire hierarchy to both sub-domain servers. Everyone authenticates locally. (why is this so difficult to grasp? I feel like this is the third or fourth time I've explained this.) His primary question, however, is if he can have 2 Samba servers providing authentication for one single Active Directory domains. This way both sites would acknowledge the users authentication within the domain. And the answer I keep giving is no, not really, but sort of if you do it with a tiered configuration. Am I right here Kenny, or did I misread the question? No, you're not understanding the answers. A member of a Windows Domain authenticates against it's Domain Controller. Hence, my answer to set it up hierarchically using LDAP. But he wants to know if he can have multiple domain controllers distributed accross two physical locations, authing off of their own copies of the LDAP tree. It answers his question, but not clearly.. ;-) And the answer is yes, but that would require cross-domain authentication in the case that someone from ou=here got to ou=there. But if you configure your LDAP acls such that 'ou=*, ou=corp, ou=foo, ou=bar' can access whatever, then you never need to cross domains. LDAP becomes you're authenticating agent in your scheme, since there is no DC per se, just a Samba server configured to hand off requests to an LDAP server. Have local DCs which authenticate users configured such that either DC will allow users from both domains to access everything via LDAP. He doesn't want 2 domains. He wants 1. Then he can't do what he wants. What's the problem with two domains? Technically, they're *sub* domains, and for all intents and purposes, he manages them as one. The users have no clue what domainn their in, nor do they care. The reason for this is that people will travel between here and there quite often, Yeah, so. Just set the ACLs up to allow anyone in 'ou=*, ou=corp, dc=foo, dc=com' access to whatever you want everyone to access. That would work, but still require maintaining two seperate directories. Seems it'd be much easier to just have one and replicate the LDAP server. This statement seems to indicate a fundamental lack of knowledge of LDAP, hierarchical design, and, well, just about everything else we're talking about here. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Ben Scott [EMAIL PROTECTED] writes: Footnotes - [1] To the best of my knowledge, anyway. If someone know of a working, stable Samba AD DC implementation, please let me know! Currently it is non-existent. [2] I understand work is underway to add AD control eventually, but until then, for stable releases of Samba, the only AD support is for Samba as an AD member (AD client). It is a *looong* way off. [3] I expect that would include keeping the NTLM password hashes in LDAP, but I don't really know. That is correct, which is one of the reasons you can almost approximate Kerberos authentication with Samba if you use the Heimdal Kerberos implementation. Heimdal allows you to store the krb5 passphrases in LDAP, which means Samba can get at them. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
[EMAIL PROTECTED] writes: The reason for this is that people will travel between here and there quite often, Yeah, so. Just set the ACLs up to allow anyone in 'ou=*, ou=corp, dc=foo, dc=com' access to whatever you want everyone to access. This is completely ineffectualy, since they will not be able to find their domain controller when they are on the other network. If there laptop is configured to look for the PDC for HERE and the only thing that they find is the PDC for THERE, then Windows will not attempt to authenticate. Hence, having the same netbios domain name in both places. The LDAP ACL's can be set to allow anyone to connect to anything, but that doesn't help if the clients won't talk to the Samba server in the first place. You're lacking some ingenuity here. Every Samba server is the PDC for it's local physical network, and a BDC for the remote network. Therefore, though HERE can't directly talk to the PDC for HERE when it's THERE. It can access the BDC for HERE, which *is* THERE. Who's on first again? Providing a backend does no good if the clients won't use it. The clients don't use it directly, Samba uses it. Without it, none of this will work. If the Windows client can't find it's authentication point, it creates a temprary profile on the system to allow login and deletes the profile when the user logs off (I hate myself for knowing this...). So, you *also* want roaming profiles? (This is part of Windows I don't know too much about. However, I have read that roaming profiles is usually a bad idea.) My (albeit limited) understanding of roaming profiles is that they're stored on the DC, no? If so, then wouldn't make it rather irrellevent whether you have one or two domains, since the profile is probably best served from a local system? If this is the case, then it would actually seem that 2 domains would be easier to deal with, since the only time a user experienced a slow log in time would be when at the other location and needing to download their profile (perhaps this is why I've read roaming profiles are bad?) As an aside, this sounds amazingly like having an NFS-based home directory and trying to NFS mount it across a T1 from 3000 miles away! Let me tell you, udp-based NFS over a T1 is *really* slow! :) Your solution creates two Windows domains. A windows system can only be a member of one domain at any given time (who ever thought that that was a good idea should be shot). Therefore, a user would have to log into the local administrator account on the laptop, change the Windows Domain, reboot, then log in. That defeats the intention of unifying the Windows domain. Or, it makes things more manageable, since you have a BDC in each location. Your definition isn't strict, it is just incorrect. No it's not, it's more strict than the normal definition, which is: the act of providing a single username/password (or whatever the credentials method is) once for access to anything during any given logon session. How and where you manage things has absolutely nothing to do with single sing-on. Sure it does. If I provide a single usernme/password to someone for access to everything, and I then have to update several different authentication devices (i.e. AD, Kerberos, and hand-full of htpasswd files, a VPN system, etc.) then I don't really have single-signon, what I have is a hodge-podge of systems which all occassionally have the same settings, but *could* at any given time be completely out of sync with each other. My definition guarantees that since there is a single location for the management of the accounts, then the username and password will always be correct and never be out of sync. Once a set of credentials has been provided by the user, access to other things (be that a system, an application, or whatever) is handled in the background without the user needing to provide said credentials again. Then, by this definition, you *need* a single management location, since, if you have a single username and password which access multiple, disjointed systems, these systems all need a central location to authenticate against. However, I am not trying to provide SSO. I am simply trying to provide a unified password infrastructure that can be centrally managed. Which is essentially the beginnings of an SSO infrastructure, and, by (my) definition, building an SSO infrastructure gets you exactly what you want :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/17/06, Paul Lussier [EMAIL PROTECTED] wrote: True, however, it would seem Kenny seems to intend to not require any auth traffic to have to go over the wire to the remote site. So in reality, when authenticating via LDAP, he'd want to replicate the LDAP server is TWO locations. Not so! You have an LDAP server in both locations, both of which are children of the ou=corp,ou=foo,ou=bar domain and allow *any member* of that super-domain access. You keep speaking in terms of LDAP servers and LDAP domains and such. Kenny's ultimate goal is to let Windows clients authenticate using NTLM. It would probably help the discussion to put things in that context. In particular, if the goal is to have a single NTLM domain, I don't know if or how that might affect the LDAP directory design. Certainly, a single NTLM domain would not be able to cope with LDAP's concept of common names made unique only by domain contexts. I would guess one would have to have some sort of directory-wide, flat, unique name attribute in that case. Something just occurred to me: If one wants to maintain a clean separation of systems between the two sites, the logical way to do this would be with two separate NTLM domains which trust each other. Create corresponding NTLM domains for each context in the LDAP tree. Have the Samba server(s) at each site be DC(s) for the the NTLM domains of the local site. Have Samba authenticate the domain to a particular context in LDAP. In this scenario, NTLM members which visit the other site (laptops) would generally want to send their authentication requests over the inter-site link. You should be able to use another Samba instance running as a BDC at the alternate site to help reduce that. I just checked the Samba HOWTO, and it claims Samba 3 does fully support the creation and maintenance of inter-domain trust relationships. See: http://tinyurl.com/bbkt4 Keep in mind that I've never tried any of the above. :-) Then he can't do what he wants. What's the problem with two domains? Two LDAP domains or two NTLM domains? -- Ben Who's on first? Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/17/06, Paul Lussier [EMAIL PROTECTED] wrote: [3] I expect that would include keeping the NTLM password hashes in LDAP, but I don't really know. That is correct, which is one of the reasons you can almost approximate Kerberos authentication with Samba if you use the Heimdal Kerberos implementation. Heimdal allows you to store the krb5 passphrases in LDAP, which means Samba can get at them. Okay, but what does any of that Heimdal/Kerberos stuff have to do with authenticating NTLM clients? I'm not being sarcastic with that question; I honestly don't understand how the two relate. (Most likely because I have little to no experience with them. I know the general Kerberos theory of operation, and I've cookbooked client config's into Linux to support Samba as an Active Directory member, but I've never setup a server or anything like that.) -- Ben I've got too much crap to learn Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/17/06, Paul Lussier [EMAIL PROTECTED] wrote: You're lacking some ingenuity here. Every Samba server is the PDC for it's local physical network, and a BDC for the remote network. Ummm... I'm pretty sure that's completely wrong. An NTLM server can only be one thing; either a member, a PDC, or a BDC. If you want a BDC, you need to run another instance of Samba. Can you site a reference please? (This is part of Windows I don't know too much about. However, I have read that roaming profiles is usually a bad idea.) I disagree strongly, and so do a great many other doze admins. Roaming profiles go a long way towards making Windows system administration tollerable. My (albeit limited) understanding of roaming profiles is that they're stored on the DC, no? The information on where to *locate* the roaming profile is stored as part of the user account, on the DCs. The actual profile can be on any server you like. If so, then wouldn't make it rather irrellevent whether you have one or two domains, since the profile is probably best served from a local system? You can (and should) do this, regardless of how many NTLM domains you have. If this is the case, then it would actually seem that 2 domains would be easier to deal with, since the only time a user experienced a slow log in time would be when at the other location and needing to download their profile (perhaps this is why I've read roaming profiles are bad?) Windoze will generally detect when the master copy (my term) of the profile is on the other side of a slow link, and used the cached profile (local copy) instead. (Or create a temporary profile, if no cached profile is available.) As an aside, this sounds amazingly like having an NFS-based home directory and trying to NFS mount it across a T1 from 3000 miles away! Pretty close. The major difference is that Windows has all user operaration occur on a local copy of the profile, and syncronizes the local copy to the master copy at logon and logoff. So you have most of the same trouble, just at different times. Let me tell you, udp-based NFS over a T1 is *really* slow! :) I'm willing to bet SMB is worse. :-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
[EMAIL PROTECTED] writes: -- Original message -- From: Thomas Charron [EMAIL PROTECTED] On 1/16/06, Paul Lussier [EMAIL PROTECTED] wrote: True, however, it would seem Kenny seems to intend to not require any auth traffic to have to go over the wire to the remote site. So in reality, when authenticating via LDAP, he'd want to replicate the LDAP server is TWO locations. Exactly. Replicate LDAP via slurpd to the remote site. The remote site has a Samba server pointing to the local replicated LDAP server. Except that the authentication traffic transiting to the remote site is a whole lot less of a probem than the roaming profiles transiting the wire. Unless you're planning on replicating the Samba configuration to both places as well, which is a *LOT* more work than just running slurpd. His primary question, however, is if he can have 2 Samba servers providing authentication for one single Active Directory domains. If that's the case, then no. Samba can not provide authentication for Active Directory Domains. As Ben pointed out, Samba, at the current time is strictly limited to serving and approximating the controller for an NT domain, which is NTLM and *DISTINCTLY DIFFERENT* than an Active Directory domain. This is exactly what I want to do. I want to have the Windows domain of CORP (why does Windows do everything in uppercase, anyway?!) in both places, each Samba server authenticating against it's local LDAP tree. I don't see any reason that this shouldn't work, since NetBIOS won't traverse the VPN, but there could be issues with SID's or RID's This should work fine, in theory... or whatever AD has these days. except YOU CAN'T SERVE AD DOMAINS WITH ANYTHING BUT A WINDOWS AD SERVER! You can serve up an NT-style NTLM domain, but not AD. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On Jan 17, 2006, at 09:55, Paul Lussier wrote: No, WinBind, from: http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/ winbind.html states that it does exactly the opposite of what is desired here. It allows a random UNIX box to authenticate against a Windows NT domain controller. Hmmm. What I know empirically is that when I setup a linux server to participate in an AD domain, to authenticate the AD users I need to have k5 and winbind working on the linux machine. Without Kerberos, you go nowhere fast. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Ben Scott [EMAIL PROTECTED] writes: -- Ben Scott I want to move to theory. Everything works there. -- Unknown Actually, I think that was me! I say that rather frequently, and I *know* I've said at Martha's before... Of course, I could have stolen it from someone else, but if so, I don't remember doing so. I'll gladly take credit for it if no one else objects :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/17/06, Bill McGonigle [EMAIL PROTECTED] wrote: Hmmm. What I know empirically is that when I setup a linux server to participate in an AD domain, to authenticate the AD users I need to have k5 and winbind working on the linux machine. Without Kerberos, you go nowhere fast. Yes. Samba uses Kerberos when running as an AD domain member (AD client). It needs to, because AD uses Kerberos as an authentication mechanism. Samba is also an LDAP client in the same role. In this role, Samba is joined to the AD domain, more or less the same way a real MS-Windows client would be. When other computers try to access resources being shared by Samba, Samba checks the credentials from the other computer against Active Directory, contacting an AD DC if needed. If you use smbclient or whatever to contact another AD member, you can use AD to authenticate yourself. However, Samba does not support running an AD Domain Controller (AD server). You need a Windows Server(TM)(C)(R) for that. Samba can be an NTLM DC or an NTLM domain member, but NTLM does not use Kerberos, LDAP, DNS, or anything else beyond NetBIOS and MS RPC. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/16/06, Dan Jenkins [EMAIL PROTECTED] wrote: Thomas Charron wrote:Umm. Note the features in Samba 3.0:*1) Active Directory support. Samba 3.0 is now able to ** joina ADS realm as a member server and authenticate ** users usingLDAP/Kerberos. * I don't know if this is entirely acurate, as Ihaven't tried it, ever, but that was one of the big points of Samba 3.The operative word here is: member.Samba 3.0 can join a Active Directory domain, but not act as a serverfor one. Ahh, I incorrectly assumed that a Samba *server* could join as a *server*.. It did say it could authenticate users, so I assumed that meant it would serve as a authentication server. Thomas
Re: Samba PDC/BDC
On 1/17/06, Paul Lussier [EMAIL PROTECTED] wrote: Thomas Charron [EMAIL PROTECTED] writes: He doesn't want 2 domains.He wants 1. Then he can't do what he wants.What's the problem with two domains?Technically, they're *sub* domains, and for all intents and purposes,he manages them as one.The users have no clue what domainn their in, nor do they care. *shrug* Only Kenny can answer that one. I'd imagine for the lazy sysadmin, it's easier.. The reason for this is that people will travel between here and there quite often, Yeah, so.Just set the ACLs up to allow anyone in 'ou=*, ou=corp, dc=foo, dc=com' access to whatever you want everyone to access. That would work, but still require maintaining two seperate directories. Seems it'd be much easier to just have one and replicate the LDAP server.This statement seems to indicate a fundamental lack of knowledge ofLDAP, hierarchical design, and, well, just about everything else we're talking about here. ... One of the, what I assumed was major, requirements was that the authentication information would not need to be transmitted over the wire every time they log in. One would assume without some sort of ESP module, that there would need to be an LDAP server in both locations Thomas
Re: Samba PDC/BDC
Ben Scott [EMAIL PROTECTED] writes: Okay, but what does any of that Heimdal/Kerberos stuff have to do with authenticating NTLM clients? Nothing, but he keeps talking about AD authentication, which Kerberos *would* be a component of if it would work. And at one point, there was a more generic single-sign on discussion which included this as well, but has since gotten lost in the noise. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Ben Scott [EMAIL PROTECTED] writes: On 1/17/06, Paul Lussier [EMAIL PROTECTED] wrote: You're lacking some ingenuity here. Every Samba server is the PDC for it's local physical network, and a BDC for the remote network. Ummm... I'm pretty sure that's completely wrong. An NTLM server can only be one thing; either a member, a PDC, or a BDC. If you want a BDC, you need to run another instance of Samba. Can you site a reference please? Ummm, I didn't mean to imply this as a default, rather I should have said: Have every samba server be the PDC for local, and the BDC for the remote domains. And yes, this would require seperate instances of Samba running on the same machine. It would also perhaps be better if they were seperate machines, but probably not necessary. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Bill McGonigle [EMAIL PROTECTED] writes: Hmmm. What I know empirically is that when I setup a linux server to participate in an AD domain, to authenticate the AD users I need to have k5 and winbind working on the linux machine. Without Kerberos, you go nowhere fast. Correct, but that's to have the linux system act as a CLIENT to the AD domain, NOT to have it act as a server. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
By coincidence I just now stumbled across this link and thought I'd pass it along on the chance it's at least of passing interest to those reading this thread: http://www.linuxformat.co.uk/modules.php?name=Newsfile=articlesid=217 I didn't read more than a few paragraphs so apologies in advance if it's just noise... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
-- Original message -- From: Paul Lussier [EMAIL PROTECTED] Ben Scott [EMAIL PROTECTED] writes: Okay, but what does any of that Heimdal/Kerberos stuff have to do with authenticating NTLM clients? Nothing, but he keeps talking about AD authentication, which Kerberos *would* be a component of if it would work. And at one point, there was a more generic single-sign on discussion which included this as well, but has since gotten lost in the noise. *HE* has been in meetings most of the day and hasn't said much of anything :-) What I originally said was that I am replacing an AD server. I inherited a Windows server that is acting as an AD domain controller. It is a terrible POS and is constantly having problems. So, I am replacing it with a Samba server. I am going to use an LDAP back end for many, many reasons. All of this is happening in the main office. We also have a branch office in another country. They want to be able to access everything here. So, the easiest way is centralized authentication. I don't want them logging into a server over there and have the auth traffic traversing the VPN every time, so I will replicate the LDAP database to a local LDAP server over there (which is really easy once you get slurpd to actually work!!). My question was originally Can I have a Samba server over there act as a PDC for them using the same Windows Domain. That question came about because it was brought to my attention that there will be traveling between here and there quite often, and re-configuring their laptops for a different windows domain is a PITA. The roaming profile thing was merely an example of the authentication process. I wasn't explicitely wanting roaming profiles (as I view them as evil). I am also not a fan of SSO. It is a human security hole. However, centralized authentication and centralized administration are good. They allow users to only have one password, and it allows me to be lazy. I see nothing wrong with this :-) But, for those of you just joining the thread, the answer so far is: 1) Yes, you can do that. 2) No, you can't do that. 3) You might be able to do that, but only if you do something completely different then what you originally wanted to do. 4)42 C-Ya, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On Jan 17, 2006, at 18:36, [EMAIL PROTECTED] wrote: They allow users to only have one password, and it allows me to be lazy. And never underestimate the value of a Post-It-Note-free security regime. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/17/06, Michael ODonnell [EMAIL PROTECTED] wrote: By coincidence I just now stumbled across this link and thought I'd pass it along on the chance it's at least of passing interest to those reading this thread: http://www.linuxformat.co.uk/modules.php?name=Newsfile=articlesid=217 More then passing interest, in my case. The short version is that yes, they (meaning the Samba 4 team) are working on having Samba be an Active Directory Domain Controller, but it is a long way off. It sounds like Bill McGonigle[1] is closer to the truth then I expected. Which is good news, I think. [1] http://www.mail-archive.com/gnhlug-discuss%40mail.gnhlug.org/msg12406.html I didn't read more than a few paragraphs so apologies in advance if it's just noise... Most of this thread has been noise. ;-) -- Ben Line Noise Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I inherited a Windows server that is acting as an AD domain controller. It is a terrible POS and is constantly having problems. I've found a lot of Windows servers are that way. I suspect that reflects the quality of both Windows itself and your typical Windows system operator. My question was originally Can I have a Samba server over there act as a PDC for them using the same Windows Domain. Well, strictly speaking, you never asked *that*. :) The answer to *that* is a firm no. You cannot have two Primary Domain Controllers in the same NTLM domain. You *did* ask if you could have a single NTLM domain, with your home-office Samba as the PDC, and the remote-office Samba act as a BDC. The short answer to that is yes. For the full treatment, see the Samba HOWTO: http://us2.samba.org/samba/docs/man/Samba-HOWTO-Collection/samba-bdc.html As I've said, I've never really done anything much with LDAP, so I've never done most of the stuff that talks about. But heck, I can at least RTFHOWTO, which is apparently more then most people around here do. ;-) In the case of a single NTLM domain, with a single Samba PDC at the home office, and a Samba BDC at the remote site, regular user authentication traffic at the remote site should use the BDC at that site. Password changes and account modifications (including machine trust account auto-updates) will have to go to the PDC (over the WAN), though. That question came about because it was brought to my attention that there will be traveling between here and there quite often, and re-configuring their laptops for a different windows domain is a PITA. As I mentioned, it should -- *in theory* -- be possible to have two NTLM domains -- one for each site. Each site's NTLM domain would have the Samba PDC for that domain at that site. You can optionally have a BDC for either NTLM domain at either site as well. Tie both NTLM domains into a single LDAP domain using different LDAP contexts in Samba. Establish NTLM trust relationships between the two NTLM domains. In that case, most of the traffic for a site stays at that site. The site's domain's PDC is local, so no cross-WAN traffic to update to the PDC for the site's domain. LDAP would still have to replicate over the WAN, but I assume you consider that acceptable. No need to disjoin/rejoin laptops. A member of one NTLM domain can use authentication data from any trusted NTLM domain. If you have a BDC for the other site's domain at each site, then a visitor's authentication traffic would stay local. The only time a visitor's NTLM domain traffic would cross the WAN is for a password change or other account update. Without BDCs, all visitor NTLM domain traffic would cross the WAN, but maybe that's not common enough for you to worry about. Again, this is all in theory. Check it first. :-) -- Ben Google Local doesn't know where 'theory' is. Darn. Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Windoze roaming profiles (was: Samba PDC/BDC)
On 1/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I wasn't explicitely wanting roaming profiles (as I view them as evil). May I ask why? I've generally found they make things a lot better. Lock down the workstations, no root access for the lusers, use domain authentication and roaming profiles. When a Windoze workstation gets screwed up (not like *that* ever happens), swap it out or re-image it. One profile sync later, the user is back up and running like nothing happened. This assumes all the clients are Win NT4/2000/XP. Win 95/98/Me are to Win NT4/2000/XP as Win NT4/2000/XP are to *nix. I've done this with both Microsoft and Samba servers, too, so it's not completely off-topic. For Samba, the critical part is to have something like logon path = \\server\profiles\%U\ in your smb.conf on the Samba DC, and [profiles] comment = Windows Roaming User Profiles path = /path/to/some/dir/ browseable = no guest ok = no writable = yes create mask = 600 directory mask = 700 csc policy = disable on the Samba server holding the roaming profile share (which can be the same server). Note that the share holding the roaming profile must *NOT* be a magic share. That is, the path must be the same for every user who connects to the share. Not the homes share. No Samba variables in the path directive. -- Ben Show me a $HOME where the buffer 'flows roam... Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/17/06, Paul Lussier [EMAIL PROTECTED] wrote: Have every samba server be the PDC for local, and the BDC for the remote domains. Ahhh, okay. Yah, that makes sense. And yes, this would require seperate instances of Samba running on the same machine. I believe you also need to bind them each to separate IP addresses, due to the way the NTLM protocol works (or fails to, rather). Still, this is a lot better then Microsoft, which requires you to have one server per domain! Still! Ick! -- Ben Microsoft is macro-hard Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Ben Scott [EMAIL PROTECTED] writes: In the case of a single NTLM domain, with a single Samba PDC at the home office, and a Samba BDC at the remote site, regular user authentication traffic at the remote site should use the BDC at that site. Password changes and account modifications (including machine trust account auto-updates) will have to go to the PDC (over the WAN), though. This is exactly what I was trying to say. Granted, I was using LDAP terminology, but the concept is exactly what I was trying to convey. As I mentioned, it should -- *in theory* -- be possible to have two NTLM domains -- one for each site. Each site's NTLM domain would have the Samba PDC for that domain at that site. You can optionally have a BDC for either NTLM domain at either site as well. Tie both NTLM domains into a single LDAP domain using different LDAP contexts in Samba. Establish NTLM trust relationships between the two NTLM domains. Other than the cross-domain trusts, which I was assuming (stupid me) was a given, I think I made exactly this suggestion, just not using these words. In that case, most of the traffic for a site stays at that site. The site's domain's PDC is local, so no cross-WAN traffic to update to the PDC for the site's domain. Exactly! LDAP would still have to replicate over the WAN, but I assume you consider that acceptable. Which I also think I mentioned. No need to disjoin/rejoin laptops. A member of one NTLM domain can use authentication data from any trusted NTLM domain. I assumed (again, silly me) that this was common knowledge. If you have a BDC for the other site's domain at each site, then a visitor's authentication traffic would stay local. The only time a visitor's NTLM domain traffic would cross the WAN is for a password change or other account update. Without BDCs, all visitor NTLM domain traffic would cross the WAN, but maybe that's not common enough for you to worry about. The only thing not being figured in here is the roaming profiles of the remote users visiting the home office. But I think you mentioned that this would be covered by latency in accessing the profile server triggering the use of a cached profile on the laptop being used instead, right? -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/17/06, Paul Lussier [EMAIL PROTECTED] wrote: Password changes and account modifications (including machine trust account auto-updates) will have to go to the PDC (over the WAN), though. This is exactly what I was trying to say. Granted, I was using LDAP terminology, but the concept is exactly what I was trying to convey. Well, like I said, the NTLM clients aren't really aware of LDAP. It's NTLM all the way to the NTLM PDC at the main office. What happens at that point is up to Samba. So LDAP replication doesn't get involved (in this part). Now, since we're on the subject, and you seem to know LDAP pretty well, I've got a question: Assume the Samba PDC at the main office passes the password change (or whatever) on to LDAP at the main office, and that all succeeds and everything. How does the LDAP server at the remote site know that the LDAP database at the home site has been updated? Does the main office LDAP server notify the remote office LDAP server somehow? And if not, will that lead to problems because the Samba PDC at the main office and the Samba BDC in the remote office have different views of the world? Other than the cross-domain trusts, which I was assuming (stupid me) was a given, I think I made exactly this suggestion, just not using these words. Well, you were going on about LDAP contexts and stuff, but you never actually mentioned that each LDAP context would have to equal a different NTLM domain. Given that Kenny was asking about using a single NTLM domain, that confused me. (And I think everyone else was already confused. (Or more likely, had lost interest. :) )) The only thing not being figured in here is the roaming profiles of the remote users visiting the home office. But I think you mentioned that this would be covered by latency in accessing the profile server triggering the use of a cached profile on the laptop being used instead, right? Yup! -- Ben LDAP must be the shortstop Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Ben Scott [EMAIL PROTECTED] writes: Well, like I said, the NTLM clients aren't really aware of LDAP. It's NTLM all the way to the NTLM PDC at the main office. What happens at that point is up to Samba. So LDAP replication doesn't get involved (in this part). I was approaching it from the context that the Samba configuration was essentially taken care of, and all the magic that had to be done was being handed off to LDAP by the Samba server. So you're right, the client side is completetly unaware of the LDAP configuration, that's all handled by Samba. Now, since we're on the subject, and you seem to know LDAP pretty well, I've got a question: Assume the Samba PDC at the main office passes the password change (or whatever) on to LDAP at the main office, and that all succeeds and everything. How does the LDAP server at the remote site know that the LDAP database at the home site has been updated? Does the main office LDAP server notify the remote office LDAP server somehow? And if not, will that lead to problems because the Samba PDC at the main office and the Samba BDC in the remote office have different views of the world? Well, at least with OpenLDAP, it's a push technology just like NIS or DNS. If you update the main LDAP server, the only way for slaves to know about that change is for the master server to push those changes out to them. With OpenLDAP this is done with slurpd. On your master server, slapd is the LDAP daemon which logs every transaction to a log, much like a log-based file system. slurpd is, for all intents and purposes a tail -f slapd.log | grep 'mod|add|del' | ldapnotify slapd-slave process. IOW, slurpd watches the replication log slapd is writing to. When it notices a change in the database, it notes that change and sends it to the slave server, which updates it's records. From: http://www.openldap.org/doc/admin23/replication.html Sample replication scenario: 1. The LDAP client submits an LDAP modify operation to the slave slapd. 2. The slave slapd returns a referral to the LDAP client referring the client to the master slapd. 3. The LDAP client submits the LDAP modify operation to the master slapd. 4. The master slapd performs the modify operation, writes out the change to its replication log file and returns a success code to the client. 5. The slurpd process notices that a new entry has been appended to the replication log file, reads the replication log entry, and sends the change to the slave slapd via LDAP. 6. The slave slapd performs the modify operation and returns a success code to the slurpd process. Well, you were going on about LDAP contexts and stuff, but you never actually mentioned that each LDAP context would have to equal a different NTLM domain. As I said, I was making assumptions that some things were self-evident :) Given that Kenny was asking about using a single NTLM domain, that confused me. (And I think everyone else was already confused. (Or more likely, had lost interest. :) )) He confused me with all the talk about the AD domains... It seemed that he was saying I want to replace an AD server with Samba and LDAP, which I took to mean that he a) thought that could be done, and b) wanted to retain whatever benefits over an NTLM domain AD offers. I hereby resign from this thread, now that we've all determined to be in violent agreement and confusion with each other. -- Seeya, Paul We're all on the same page, their just in different languages ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Tom Buskey [EMAIL PROTECTED] writes: Samba as a PDC w/o any windows servers. Just clients. Check out the Samba guides from the Bruce Perens series by PTR (which, btw, are all downloadable in pdf from the side). I don't remember the site, but googling for Bruce Perens PTR ought to get you there eventually :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On Jan 16, 2006, at 11:26, Paul Lussier wrote: Windows clients can not do resolution against one entity (LDAP) and authentication against another (Kerberos) *unless* it's against Active Directory. AD does use LDAP and Kerberos for most of its heavy lifting. Do we know what the missing magic pixie dust is to tie this together? Samba can not authenticate against Kerberos. Doesn't winbind accomplish this? -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/16/06, Paul Lussier [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: While I thouroughly enjoyed the well thought out LDAP plan, if you notice, my question was more about the Samba set up. I already have LDAP set up in much that fashion. There are a few things that I did differently, but mostly it's the same.You seem to think there's a separation of components here.Not so. Setting Samba up to use LDAP means to authenticate against LDAP.Therfore, your LDAP configuration plays an extremely important part inyour Samba configuration, since it becomes the authenticating agentfor the clients.Your samba server is going to hand off all authentication and authorization requests from the client to the LDAPserver! True, however, it would seem Kenny seems to intend to not require any auth traffic to have to go over the wire to the remote site. So in reality, when authenticating via LDAP, he'd want to replicate the LDAP server is TWO locations. His primary question, however, is if he can have 2 Samba servers providing authentication for one single Active Directory domains. This way both sites would acknowledge the users authentication within the domain. Am I right here Kenny, or did I misread the question? My question, however, was on the Windows Domain. Can I have the same Windows Domain in both places (regardless of where they actually authenticate). A member of a Windows Domain authenticates against it's DomainController.Hence, my answer to set it up hierarchically using LDAP. But he wants to know if he can have multiple domain controllers distributed accross two physical locations, authing off of their own copies of the LDAP tree. It answers his question, but not clearly.. ;-) LDAP becomes you're authenticating agent in your scheme, since thereis no DC per se, just a Samba server configured to hand off requests to an LDAP server.Have local DCs which authenticate users configuredsuch that either DC will allow users from both domains to accesseverything via LDAP. He doesn't want 2 domains. He wants 1. The reason for this is that people will travel between here and there quite often,Yeah, so.Just set the ACLs up to allow anyone in 'ou=*, ou=corp, dc=foo, dc=com' access to whatever you want everyone to access. That would work, but still require maintaining two seperate directories. Seems it'd be much easier to just have one and replicate the LDAP server. I considered doing this, but I just don't have the time to play with Kerberos.Kerberos is about 20 min. to install and configure by my estimates. (I've not actually installed kerberos, but after managing it for 2.5years, I can't see what would take much more than that.Installingthe OS will take longer than setting up Kerberos.)I'll concede, youneed to first understand what kerberos is, but reading the installation manual from MIT pretty much walks you through this andgets you set up fairly quickly. Not only that, but alot of the wizards out there make it relatively painless. Untill it breaks somewhere.. ;-) Thomas
Re: Samba PDC/BDC
-- Original message -- From: Paul Lussier [EMAIL PROTECTED] [EMAIL PROTECTED] writes: You seem to think there's a separation of components here. Not so. Setting Samba up to use LDAP means to authenticate against LDAP. Therfore, your LDAP configuration plays an extremely important part in your Samba configuration, since it becomes the authenticating agent for the clients. Your samba server is going to hand off all authentication and authorization requests from the client to the LDAP server! There is (or at least, can be) a separation of componants. The Windows Client authenticates to the Samba server. It knows nothing about the LDAP server. It is merely talking to the PDC for DomainName. The Samba server is configured to authenticate against a given point in the LDAP directory (i.e. ldap user suffix = ou=foo,ou=corp or ou=bar,ou=corp or ou=*,ou=corp). So, while the Windows clients are talking to what they view as a PDC of DomainName, the samba server is checking the credentials against ou=foo,ou=corp,dc=comapny,dc=com or, if the location is different, ou=bar,ou=corp,dc=comapny,dc=com, or whatever search subtree it has. The Windows Domain remains the same, as it is a netbios name, but the place in the LDAP tree is different depending on the smb.conf. My question, however, was on the Windows Domain. Can I have the same Windows Domain in both places (regardless of where they actually authenticate). A member of a Windows Domain authenticates against it's Domain Controller. Hence, my answer to set it up hierarchically using LDAP. LDAP becomes you're authenticating agent in your scheme, since there is no DC per se, just a Samba server configured to hand off requests to an LDAP server. Have local DCs which authenticate users configured such that either DC will allow users from both domains to access everything via LDAP. The reason for this is that people will travel between here and there quite often, Yeah, so. Just set the ACLs up to allow anyone in 'ou=*, ou=corp, dc=foo, dc=com' access to whatever you want everyone to access. This is completely ineffectualy, since they will not be able to find their domain controller when they are on the other network. If there laptop is configured to look for the PDC for HERE and the only thing that they find is the PDC for THERE, then Windows will not attempt to authenticate. Hence, having the same netbios domain name in both places. The LDAP ACL's can be set to allow anyone to connect to anything, but that doesn't help if the clients won't talk to the Samba server in the first place. I read it. It was a while back, but it's a good book. Read it again. I suggest you read up on how Windows actually does things (I don't actually suggest this, as it is fairly insane how Windows does some things :-). Providing a backend does no good if the clients won't use it. I'm not saying that Windows does things correctly (as it is quite obvious that it is completely broken behavior, IMO). LDAP is the backend to Samba. Samba is the authentication point to the Windows clients. If the Windows client can't find it's authentication point, it creates a temprary profile on the system to allow login and deletes the profile when the user logs off (I hate myself for knowing this...). Your solution creates two Windows domains. A windows system can only be a member of one domain at any given time (who ever thought that that was a good idea should be shot). Therefore, a user would have to log into the local administrator account on the laptop, change the Windows Domain, reboot, then log in. That defeats the intention of unifying the Windows domain. You should read the Paranoid Penguin in LJ. They explain how to pull the Windows systems into single sign-on environment. I did, they don't, you can't. I haven't read part 3 yet (just came in last friday..). I was left with the impression that there was a way to do it. Yep, MIT Kerberos for Windows works great. Still doesn't get you single sign-on. By the way, my definition of single sign-on is rather strict. Not only must the user be able to use the same username and passphrase everywhere, but I as the administrator must have only and exactly *1* location in which to manage *everything*. This is not possible today in a heterogeneous environment which includes products from Microsoft. Your definition isn't strict, it is just incorrect. How and where you manage things has absolutely nothing to do with single sing-on. SSO is the act of providing a single username/password (or whatever the credentials method is) once for access to anything during any given logon session. Once a set of credentials has been provided by the user, access to other things (be that a system, an application, or whatever) is handled in the background without the user needing to provide said credentials again. However, I am not trying to
Re: Samba PDC/BDC
These should get you started: http://www.donour.com/prof/cifs2002.pdf. http://info.ccone.at/INFO/Samba-2.2.12/Samba-PDC-HOWTO.html http://www.dekart.com/support/howto/Howto-Logon-Samba/Samba_domain_controller/ FYI, Kenny -- Original message -- From: Tom Buskey [EMAIL PROTECTED] Samba as a PDC w/o any windows servers. Just clients. On 1/16/06, Paul Lussier [EMAIL PROTECTED] wrote: Tom Buskey [EMAIL PROTECTED] writes: Are there any good guides to this? Guides to what ? LDAP and Samba? Kerberos? Using all 3 together? -- Seeya, Paul -- A strong conviction that something must be done is the parent of many bad measures. - Daniel Webster ---BeginMessage--- Samba as a PDC w/o any windows servers. Just clients.On 1/16/06, Paul Lussier [EMAIL PROTECTED] wrote:Tom Buskey [EMAIL PROTECTED] writes: Are there any good guides to this?Guides to what ?LDAP and Samba? Kerberos?Using all 3 together?--Seeya,Paul-- A strong conviction that something must be done is the parent of many bad measures. - Daniel Webster ---End Message---
Re: Samba PDC/BDC
On 1/16/06, Thomas Charron [EMAIL PROTECTED] wrote: His primary question, however, is if he can have 2 Samba servers providing authentication for one single Active Directory domains. This way both sites would acknowledge the users authentication within the domain. A point which appears to be a source of confusion in this discussion: Samba cannot act as an Active Directory Domain Controller. Period.[1][2] Samba can act as an NTLM Domain Controller. It act as a PDC (Primary Domain Controller). It can also act as a BDC (Backup Domain Controller) for purposes of providing authentication to domain members. However, Samba does not implement Microsoft's PDC/BDC replication protocols. You have to use LDAP to provide the backend for authentication data storage and replication. Corollary: If you are using Samba as a DC, you are running things as an NTLM domain, *NOT* an Active Directory domain, with all the limitations and consequences thereof. In particular, the domain members will all be using NetBIOS and MS RPC, and will have no awareness of LDAP for purposes of the Windows domain. I know next to nothing about LDAP, so I haven't had anything much of useful to add to this discussion, but this appears to be a point of confusion, so I thought I would clarify it. My understanding (which, again, is woefully incomplete) is that Kenny will have to store all authentication information[3] in LDAP, and point all his Samba DCs at LDAP. One of the Samba DCs will need to be designated the PDC; all the rest will be designated BDCs. Everything really goes back to LDAP, of course, but the NTLM protocol is built around a master/slave model, and Samba has to be configured to match. In this scenario, the domain members speak NTLM to Samba, and don't know anything about LDAP. The LDAP server(s) speak LDAP to Samba, and don't know anything about NTLM. Samba acts as a sort of gateway between the two worlds. NTLM password changes would have to go to the Samba PDC, which would presumably push them to LDAP, which would then provide updated answers to all the Samba BDCs. Hope this helps, Footnotes - [1] To the best of my knowledge, anyway. If someone know of a working, stable Samba AD DC implementation, please let me know! [2] I understand work is underway to add AD control eventually, but until then, for stable releases of Samba, the only AD support is for Samba as an AD member (AD client). [3] I expect that would include keeping the NTLM password hashes in LDAP, but I don't really know. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If the Windows client can't find it's authentication point, it creates a temprary profile on the system to allow login and deletes the profile when the user logs off (I hate myself for knowing this...). What you are describing are roaming user profiles, which are only slightly related to authentication. When a user attempts to log on to a domain, the domain member (client) will attempt to find a DC for the domain. If a DC cannot be found, the client will check to see if it has cached credentials from a previous logon to that machine. If so, the user will be logged in using those cached credentials. Otherwise, the logon will fail. Roaming profiles are unrelated to that, except that the DC informs the client of the network location of the master copy (my term) of the user profile. (I'm told you can even set this without a domain at all, although I've never gotten it to work right.) When a roaming profile location exists, the client will attempt to access the network copy of the profile. Assume it succeeds, it will be copied to the local machine, and used for the user's logon session. On logoff, changes are synchronized with the network again. If the network profile (master copy) is *NOT* available, behavior depends on history. If the user has never logged on to the client before, the behavior will be as you describe: A temporary profile is created at logon, and discarded at logoff. If the user has logged on before, a (possibly very old) copy of their profile will already exist locally. The client will use that instead. (This makes for confusion when someone gets an old copy of their user profile due to a combination of network unavailability and workstation sharing.) This doesn't even consider client folder redirection or offline files, which introduce their own truckloads of worms. SSO is the act of providing a single username/password (or whatever the credentials method is) once for access to anything during any given logon session. I've encountered two usages for the term SSO. One is your usage: The user signs on once, and everything else derives from that. The other usage is, The user has one sign-on [set of credentials], which they use everywhere. However, they may be asked to enter those same credentials more then once. I'm not interested in debating the correctness of a particular usage; just pointing out that there are two usages. -- Ben Knows too much about Windows Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
-- Original message -- From: Ben Scott [EMAIL PROTECTED] On 1/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If the Windows client can't find it's authentication point, it creates a temprary profile on the system to allow login and deletes the profile when the user logs off (I hate myself for knowing this...). What you are describing are roaming user profiles, which are only slightly related to authentication. Yeah, I know. I was just demonstrating what happens when a laptop configured as a member of the HERE domain can't find it's DC. IOW, it doesn't try to authenticate against the DC for the THERE domain. I wasn't trying to give an in depth explanation of the Windows world. That would take too much time, and I would confise myself. Not to mention, most people really don't care how it all works (when it works, that is :-) C-Ya, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yeah, I know. I was just demonstrating what happens when a laptop configured as a member of the HERE domain can't find it's DC. IOW, it doesn't try to authenticate against the DC for the THERE domain. Ah. Yes. To further expand upon that (for the benefit of you or others): Suppose we have two SMB domains, FLINSTONE and RUBBLE. Each has one DC: FRED is the DC for FLINSTONE; BARNEY is the DC for RUBBLE. We have a client, PEBBLES, which is a member of the FLINSTONE domain. The two domains trust each other. PEBBLES will only contact FRED for authentication services. Even if someone with a user account from the RUBBLE domain tries to log on to PEBBLES, PEBBLES will *not* contact BARNEY directly. PEBBLES still passes the authentication request on to FRED. The client is not responsible, or even much aware, of domain trusts. Since the FLINSTONE domain has a trust relationship with RUBBLE, FRED will pass the authentication request from PEBBLES on to BARNEY. Assuming the request succeeds, BARNEY will return a token to FRED, who in turn passes it on to PEBBLES for the user's logon session. Note that any or all of the above can take place with Samba, so this isn't necessarily a doze-only scenario. (Although why you'd use SMB in a homogeneous nix environment, I don't know.) Hmmm, wait, come to think of it, I don't actually know if Samba-as-a-DC lets you create trusts between the Samba-controlled domain and other domains. But the rest is all there. (Samba will definitely recognize a trust relationship created in other domains.) ... most people really don't care how it all works (when it works, that is :-) Isn't it always that way? :-) -- Ben Scott I want to move to theory. Everything works there. -- Unknown ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Apparently the magic pixie dust is some sort of RPC mechanism. Found this here: http://info.ccone.at/INFO/Samba/Samba-Guide/kerberos.html - Active Directory Replacement with Kerberos, LDAP, and Samba The Microsoft networking protocols extensively make use of remote procedure call (RPC) technology. Active Directory is not a simple mixture of LDAP and Kerberos together with file and print services, but rather is a complex intertwined implementation of them that uses RPCs that are not supported by any of these component technologies and yet by which they are made to interoperate in ways that the components do not support. In order to make the popular request for Samba to be an Active Directory Server a reality, it is necessary to add to OpenLDAP, Kerberos, as well as Samba, RPC calls that are not presently supported. The Samba Team has not been able to gain critical overall support for all project maintainers to work together on the complex challenge of developing and integrating the necessary technologies. Therefore, if the Samba Team does not make it a priority to absorb Kerberos and LDAP functionality into the Samba project, this dream request can not become a reality. At this time, the integration of LDAP, Kerberos, and the missing RPCs is not on the Samba development roadmap. If it is not on the published roadmap, it cannot be delivered anytime soon. Ergo, ADS server support is not a current goal for Samba development. The Samba Team is most committed to permitting Samba to be a full ADS Domain member that is increasingly capable of being managed using Microsoft Windows MMC tools. - All that given, I'd be willing to chip in a hundred bucks for a bounty on said working RPC mechanism. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/16/06, Bill McGonigle [EMAIL PROTECTED] wrote: Apparently the magic pixie dust is some sort of RPC mechanism.Found this here: http://info.ccone.at/INFO/Samba/Samba-Guide/kerberos.htmlAt this time, the integration of LDAP, Kerberos, and the missingRPCs is not on the Samba development roadmap. If it is not on thepublished roadmap, it cannot be delivered anytime soon. Ergo, ADS server support is not a current goal for Samba development. The SambaTeam is most committed to permitting Samba to be a full ADS Domainmember that is increasingly capable of being managed using MicrosoftWindows MMC tools. Umm. Note the features in Samba 3.0: 1) Active Directory support. Samba 3.0 is now able to join a ADS realm as a member server and authenticate users using LDAP/Kerberos. I don't know if this is entirely acurate, as I haven't tried it, ever, but that was one of the big points of Samba 3. Thomas
Re: Samba PDC/BDC
On Monday 16 January 2006 05:48 pm, Thomas Charron wrote: Umm. Note the features in Samba 3.0: *1) Active Directory support. Samba 3.0 is now able to ** join a ADS realm as a member server and authenticate ** users using LDAP/Kerberos. * I don't know if this is entirely acurate, as I haven't tried it, ever, but that was one of the big points of Samba 3. Thomas I've done this. Yes, it is accurate - a Samba3 box can join an ADS. However, it cannot act as primary domain controller in ADS, just another lowly member. -N ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Thomas Charron wrote: On 1/16/06, Bill McGonigle [EMAIL PROTECTED] wrote: At this time, the integration of LDAP, Kerberos, and the missing RPCs is not on the Samba development roadmap. If it is not on the published roadmap, it cannot be delivered anytime soon. Ergo, ADS server support is not a current goal for Samba development. The Samba Team is most committed to permitting Samba to be a full ADS Domain member that is increasingly capable of being managed using Microsoft Windows MMC tools. Umm. Note the features in Samba 3.0: *1) Active Directory support. Samba 3.0 is now able to ** join a ADS realm as a member server and authenticate ** users using LDAP/Kerberos. * I don't know if this is entirely acurate, as I haven't tried it, ever, but that was one of the big points of Samba 3. The operative word here is: member. Samba 3.0 can join a Active Directory domain, but not act as a server for one. -- Dan Jenkins ([EMAIL PROTECTED]) Rastech Inc., Bedford, NH, USA --- 1-603-206-9951 *** Technical Support Excellence for over a quarter century ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On 1/16/06, Bill McGonigle [EMAIL PROTECTED] wrote: Apparently the magic pixie dust is some sort of RPC mechanism. Found this here: http://info.ccone.at/INFO/Samba/Samba-Guide/kerberos.html I read that as a bit more then an RPC mechanism. I read that as saying, in order to be an AD DC, Samba would have to have all the functionality it has now, plus all the functionality of an LDAP server, plus all the functionality of a Kerberos server. (Alternatively, much of the functionality of Samba would have to be fitted into an LDAP implementation and a Kerberos implementation. Six of one, half-dozen of the other.) That fits the pattern of how Microsoft designs things: Very high coupling, and poor cohesion. Everything is all tied together in a big knot. ADS server support is not a current goal for Samba development. Darn. I can't say I'm surprised. Heck, I'm more surprised that Samba works at all, let alone as a mostly-complete replacement for NTLM. It's not like Microsoft is known for enabling interoperability. But still: Darn. -- Ben Darn Scott ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
On Jan 16, 2006, at 18:24, Ben Scott wrote: I read that as saying, in order to be an AD DC, Samba would have to have all the functionality it has now, plus all the functionality of an LDAP server, plus all the functionality of a Kerberos server. We have all those parts. It's unix. We link libraries. :) -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC/BDC
Are there any good guides to this?I have an environment with several (6) Solaris 10 boxes w/ NIS and 2 Win XP Pro PCs. I have DNS only because the PCs don't do NIS for name resolution.Right now, I have Samba for home directories, but I want to do roaming profiles, etc so nothing is on the PC drives. I want all data, etc on the RAID disk I have on the server. It'd be nice to use just one place for passwords vs NIS/each PC/smbpasswd (or the tldb thing in samba really).I'm not sure I want to do LDAP because it's such a small environment and I'm not that familiar with LDAP. Maybe it's easier then I think. BTW this is an isolated environment. No connection to any other network. Ever.ob linux I'll probably add a linux box to the mix doing Big Sister or something else that'll measure performance in graphs and do some monitoring. /ob linux -- A strong conviction that something must be done is the parent of many bad measures.- Daniel Webster
Samba PDC/BDC
Hi All, I am in the process of replacing a Windows AD Domain controller with Samba and LDAP. I have another office elsewhere in the world that is connected via an IPSEC VPN. I want to create a secondary Samba/LDAP server in that office so that they can authenticate against a local server rather then having to traverse the VPN tunnel several times. Replicating LDAP is pretty easy using slurpd and maintains the centralized management model that I am trying to build (create a user here, and they can log in over there). My question is more on the Samba side of things. Can I build the Samba server over there as a BDC like in the old days when there was a concept of a PDC and a BDC? Can I still have both Samba servers act as a domain controller for the same Windows domain? I haven't displaced Active Directory before, so what pitfalls should I be aware of? Is there anything non-obvious to setting up the same domain in two places? TIA, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Samba PDC
Hi All, This is a simple one I am replacing a Windows AD Domain controller with a Samba PDC and LDAP. I have Samba and LDAP set up using a different windows domain name so that I can test things out. However, I want to pre-poulate the Samba PDC with machine accounts, users, etc. while the Windows AD PDC is running. When I am ready to make the switch, can I change the domain name in Samba and LDAP and go, or do I have to go live with the new name before adding users/workstations/etc. because of the SIDs, et al? TIA, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC
Without wasting too much effort, can't you just put a few objects in your new directory and then try to change it's domain to yet a third unused domain and see what happens? It sounds doable, but I wouldn't try doing something like that without a dry run first. -N Hi All, This is a simple one I am replacing a Windows AD Domain controller with a Samba PDC and LDAP. I have Samba and LDAP set up using a different windows domain name so that I can test things out. However, I want to pre-poulate the Samba PDC with machine accounts, users, etc. while the Windows AD PDC is running. When I am ready to make the switch, can I change the domain name in Samba and LDAP and go, or do I have to go live with the new name before adding users/workstations/etc. because of the SIDs, et al? TIA, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Samba PDC
Now why didn't I think of that?? (oh, right, because I work for a startup moving a million miles a minute without time to think of the obvious :-) Thanks, Kenny -- Original message -- From: Neil Schelly [EMAIL PROTECTED] Without wasting too much effort, can't you just put a few objects in your new directory and then try to change it's domain to yet a third unused domain and see what happens? It sounds doable, but I wouldn't try doing something like that without a dry run first. -N Hi All, This is a simple one I am replacing a Windows AD Domain controller with a Samba PDC and LDAP. I have Samba and LDAP set up using a different windows domain name so that I can test things out. However, I want to pre-poulate the Samba PDC with machine accounts, users, etc. while the Windows AD PDC is running. When I am ready to make the switch, can I change the domain name in Samba and LDAP and go, or do I have to go live with the new name before adding users/workstations/etc. because of the SIDs, et al? TIA, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
