Real networking over "simple file sharing"

[latrosicarius]

Hi, I have a question about networking. I guess I'm pretty good at normal networking (Internet Connection Sharing, file sharing, router, switches, hubs, hell, I even made my own CAT6 cables for a completely gigabit-compliant network).

But there's one area that I'm a complete n0ob. At my work, there's like 100 computers in the building and everybody "logs in" to some sort of server (i've never seen it) that is on some sort of domain. For instance, when you log in, you have to type <domain>\<user name> and then your password. They give you your user name and a temporary password, and they make you change it to whatever you like by logging in your first time.

Well, I want to do something like this for my home network, since I have like 8 different computers, as well as a stand-alone "server" computer with a large RAID array of drives (1.2TB). I try to enforce that everyone saves stuff on the server b/c it backs up automatically, yet people are reluctant to do so b/c they have personal files that they do not wish to share. So the point is a common "shared folder" is not sufficient.

At my work, they also get around this by having public folders AND private folders, where only your user name can access.

I'm wondering if anyone can tell me what OS is necessary for this (not XP pro?), and how to get a "domain" so that people can log into the server in the way I stated above. Also, if anyone knows of a good tutorial page, I'd be very thankful since every single page seems to be about "home office networking" not REAL networking.

Thanks!

[Paul Adams]

Here's a quick* "Windows Networking 101" to try to answer some of your questions...

In short, you will require a domain for this to work as you want.
Computers in a workgroup are just a collection of independent, standalone clients with their own very personal view of "the world", and they do NOT trust any outside accounts (user or computer).

Because of this, you can have "John Smith" as a user on computer A and another "John Smith" on computer B - these are entirely different user accounts and can have different passwords, details, files, etc.

In order to have a degree of trust between the machines, you need a single authority that all of them trust - a domain (or "Active Directory").
With at least one domain controller, the machines can now join this concept of a unified view of the world and you can have user accounts which are trusted by all of them (the permissions for these accounts are defined at the domain or machin level).

Now, you can only have one "John Smith" as a domain user account, to ensure uniqueness, and every machine that is in the domain should be able to authenticate this user logging on - so long as the domain controller can be contacted.

Technical limitation to note here - Windows XP Professional is required to join a domain.

A machine that is a member of a domain can use local users or domain users to authenicate - in either case on a successful logon a user profile is created with specific exclusive access control rights given to this user account, so here are your private files per-user.
All flavours of Windows from 2000 upwards have these "My Documents", "My Pictures", etc you will have seen - these are stored within your user profile to keep them accessible only by you (unless you start playing with "My Shared Documents".

Private or shared folders on a file server work the same way, but specifically with domain user accounts - you can automate some of this stuff with redirected folders, roaming profiles, etc. but at the basic level the share simply has a list of domain user accounts that are permitted different levels of access to the folder.

So, as long your "server" is actually a member of the Windows Server family (Windows 2000 Server or Windows 2003 Server) then it could become a domain controller - however the client machines need to be able to join a domain also.

A domain is not just about file sharing, however, it is a very complex and powerful thing and there are courses and books dedicated to only portions of how to configure, use, extend, modify and integrate with them - so this is not a small subject.

To be honest, your problem is best solved with a method of password-protecting the files themselves, as I'm not sure if XP Home can disble "simple file sharing" (never actually played with the Home versions on networks as I only ever see corporate installs).
"Simple file sharing" basically defaults to using the Guest account on remote machines, so all the clients authenticate as the same (anonymous) user and there is no concept of individual permissions.


What you could do is share out specific folders on the server with a $ appended to the end of the name, so they are not visible when browsing the server - then have each client machine use a persistent mapping to their own shares.
It is common to have H: (for "Home") mapped to a location where users store their personal files, and a different letter (or set of letters) for common/shared folders.

So on the server your folder structure might look like:
D:\Public
D:\Funnies
D:\Users\Mary
D:\Users\Bob
D:\Users\Janet

Your shares might be set up thus, with Guest access allowed for all:
Public = D:\Public
Funnies = D:\Funnies
MarySecretShare$ = D:\Users\Mary
BobPrivateFiles$ = D:\Users\Bob
JanetsStuff$ = D:\Users\Janet

Anyone browsing to the server will only see Public and Funnies.
Mary should be logged onto a client then have H: mapped (with "reconnect at logon") to MarySecretShare$.
Similary, Bob and Janet log on and have H: persistently mapped to their unique sharenames.

This is not a secure solution of course, just a way to obscure the files that people want to be private - but it's a no-cost way you could help them a little bit immediately.


Going into a domain environment for such a tiny network might be a sledgehammer to crack a walnut, there are most likely other ways to use 3rd party apps for authentication-based file sharing.
I know that NAS boxes are becoming popular in the US, and I think some may have file synchronisation & user-based authentication built in - but I've not paid much attention to them.

(By user-based authentication I mean the user would be prompted to provide a name and password when they attempt to access a resource, rather than have it occur seamlessly with Windows authentication.)


* Okay maybe I lied about "quick", but this is the tip of a very large iceberg - even large companies don't utilise the full potential of domains
I don't know if this helped or just made things more confusing!

[Moby-Dick]

You can run a windows domain on everythiing ( just about ) from windows NT server upwards

Pauls covered a lot in his post - but as he said, it really is a huge subject.

You should be able to get hold of a 120 day evaluation version of Server 2003 , to at least have a try with building a domain , and adding users to it.

[latrosicarius]

Wow! Lots to read, but I read every word

I think I will try the eval version of Win Server 2003 and see how I like the whole domain aspect. I know it's a big deal to run a real network, but I'm mostly wanting to do it out of curiosity b/c it
s the logical next step of skill development for me. I'm glad you guys took the time to write those posts. My only question at this point is, is this the same kind of "domain" as an Internet domain (.com, .org, .co.uk, etc.)? Does this mean that I'd have to purchase a website in addition to the server OS?

Thanks a ton!

[Splash]

In short no - generally an Active Directory domain name will be domain.local.

[Paul Adams]

Originally Posted by latrosicarius

My only question at this point is, is this the same kind of "domain" as an Internet domain (.com, .org, .co.uk, etc.)? Does this mean that I'd have to purchase a website in addition to the server OS?

No, a Windows "domain" is not associated with an internet domain name, you don't need to buy an internet domain name.
Though if you intended to ever host your own website and have a large internal network, this is where planning the Windows domain structure would be an important step BEFORE deploying the first domain controller (DC).

One reason being, say I register the internet domain "mydomain.com" and set up a domain controller using this same name, but on my private internal network.

Now say I have a website hosted elsewhere, accessible via http://www.mydomain.com or http://mydomain.com - these would have to resolve to public IP addresses for the outside world to see this website.

Part of Windows domain functionality is provided by the fact that every domain controller will actually have a slightly different view of what "mydomain.com" is, in terms of DNS - and they CANNOT point to the public IP address of the website.
This would mean that members of the domain would be unable to visit the website via http://mydomain.com, as they would end up talking to a DC which would simply reply with "huh?".

In your case not a big issue, but this is just to highlight the difference in the namespaces and why you shouldn't jump in and start building DCs for companies without careful planning (though MANY people do).
Not much good if your employees can't even acces the company website when the customers can.

Recommendation is not use a domain which could exist on the Internet, and typical practice is to prepend "corp." in front of the domain name for Windows' use.
e.g. the public internet domain would be "mydomain.com" and the Windows domain would be "corp.mydomain.com"

Also, don't use "single-label domains" such as "home", and don't use other companies' internet domain names.

Small Business Server defaults to a ".local" domain, but this would never be potentially connectable with the Internet to join public namespaces.

[Moby-Dick]

while you can name your domain with an externally reachable domain name , its generally considered not to be a good idea. As splash said , most people tend to use a .local extenstion for the active directory root domain.

You'll find out that as you build your domain , that coreect local DNS resolution is key to your active directory functioning - the fist thing my networking tutor put on the board in large letters was ( NO DNS = NO AD )


nb. if you are using wondws NT , then DNS doesn't matter as NT domains do not use DNS in the same way, they'd rather use WINS , but I dont want to over complicate the issue

[Moby-Dick]

Small Business Server defaults to a ".local" domain, but this would never be potentially connectable with the Internet to join public namespaces.

which imo is a good thing , it does mean a few more steps ( and another DNS zone somwhere ) but its more flexible

the only case where it is a pain is when you are setting LCS SRV records in DNS

[SilentDeath]

For what your going to use it for, would it not be better to use an ftp server or just do it with normal passworded file share?

[KW1816]

Paul,

Here's a quick* "Windows Networking 101" to try to answer some of your questions...

Excellent post - If you don't mind I think I'll pinch it for work, save me spending hours trying to explain it to the newbies we get every year. It can't be intern time again can it

[latrosicarius]

Awesome, thanks so much for posting, everyone.

Just for clarification, if I want to eventually use my server for an FTP server (I don't need to do a whois--typint the IP address is fine), I should not use .local? It should be something like "ftp.xxx.xx.xx.xx" for the FTP, and something like "net.xxx.xx.xx.xx" for the local network?

(however, when I'm on the inside, I can use "ftp.localhost" & "net.localhost"?)

I appreciate your respnses, sorry for asking more info, but I'm kind of a noob when it comes to DNS stuff. Thanks!

[Paul Adams]

Originally Posted by latrosicarius

...if I want to eventually use my server for an FTP server (I don't need to do a whois--typint the IP address is fine), I should not use .local? It should be something like "ftp.xxx.xx.xx.xx" for the FTP, and something like "net.xxx.xx.xx.xx" for the local network?

(however, when I'm on the inside, I can use "ftp.localhost" & "net.localhost"?)

Right, not sure what you mean by "net.localhost", but in essence if you intend to have your server accessible from the Internet using the public IP address (which would NAT to your private server IP) then you don't need to be concerned about names or DNS at all.


The label "localhost" traditionally translates to 127.0.0.1 which is the loopback address - effectively a machine's way of saying "me" when referring to itself on the network.

The problems you run into with DNS are with internal clients, if you called your Windows domain microsoft.com for example then you could encounter problems reaching the Microsoft website because your clients would get referred to your domain controllers for the name "microsoft.com".

I have seen this problem occur with a few companies who didn't plan their AD correctly and then ask how they can get their clients to use http://mycompany.com and have it work - all to avoid typing "www." at the start.

There is nothing to stop you using the domain name blahblahblah.zzz.wooooobong.wibble if you really felt so inclined.
It would never be reachable by this name on the Internet, but it should be fine for a Windows domain.
Hell of a thing to type in when joining your domain, however.


One thing to bear in mind is that another way to authenticate against AD is to use a "Universal Principal Name", or UPN.

This is your username, followed by an @, followed by your AD DNS name.
e.g.
Domain name = wowzers.lookatme.com
NetBIOS domain name = WOWZERS
User name = BobTheMighty

Traditional logon would be WOWZERS\BobTheMighty
UPN logon would be BobTheMighty@wowzers.lookatme.com

The reason? People tend to remember email addresses more easily than domain/user combinations.


Similarly, your machine names would register in local DNS as machinename.domainname - so for a machine called HAL2000 you might have the name HAL2000.blahblahblah.zzz.wooooobong.wibble as far as your internal clients are concerned.
Then you can just use the command "ftp HAL2000.blahblahblah.zzz.wooooobong.wibble" from a client and it will resolve to that server's private IP address correctly and connect to the FTP server service.

[latrosicarius]

Oh thanks, I see what you mean--localhost would only work from the server itself, not the clients in the network. What I meant by "net.xxx.x.x.xx" was a variation of what you said of "corp.domain.com", except that I am not a corperation so I just changed it up a bit.

So my thinking would be that the active directory would be "net.xxx.x.x.xx", and later when I set up the FPT site, it will be "ftp.xxx.x.x.xx". I'm not sure if this is "best practices" or not though.

Also, the xxx.x.x.xx would be the server's internal IP and due to the dynamic nature of a non-commercial ISP, the only way to access the ftp or network from outside the LAN would be to type in the current router IP address, which would port forward all incomming connections to the server's internal IP.

^ lol, I think I have it right... just thinking out loud.

Thanks again

[latrosicarius]

Follow up:

Just letting you guys know that I DL'ed the 180-day trial of Win Server 2003 from microsoft.com and installed it. Setting up the server was a snap and I ended up using a domain name of:

homenet.local

So, logging in on a client PC (like I am right now), I use the following for logging onto the Active Directory:

homenet\<user name>

Just saying thanks for your help, but I do have a few more questions:

1.) It's slower to log on than normal. I know it's because it has to talk over the LAN, but it's even slower than at work, and I have a fully Gigabit (1-Gbps) network, whereas at work we only have Megabit (1-Mbps). It's not slow for accessing files, only for logging on.

2.) I can't seem to be an administrator on my client PC with the user name that I log into the server with. I know this is possible b/c I am an administrator on my work client. Furthermore, at work, the HelpDesk has the ability to remotely grant me administrative privelages on my client PC (without physically comming to my PC). I'm wondering how to do this... maybe not remotely, but at least make me an admin on my own client.

Thanks!

[Paul Adams]

Originally Posted by latrosicarius

1.) It's slower to log on than normal. I know it's because it has to talk over the LAN, but it's even slower than at work, and I have a fully Gigabit (1-Gbps) network, whereas at work we only have Megabit (1-Mbps). It's not slow for accessing files, only for logging on.

Okay, the thing with slow logons is you have to know where the delay occurs.
What I mean is the logon process from entering your credentials to having your desktop up has some key points in it - you need to describe a) where the delay occurs and b) how long it is.

1. You initially enter your credentials and the window greys out the input boxes
2. The logon window vanishes and the first status window appears
3. "Applying your user settings" (or similar, I forget the exact text) appears
4. Any logon scripts from group policies are executed
5. Any post-logon scripts on the local machine are executed
6. Your desktop is up and you are logged in

You might want to look into "userenv logging" to check the logon process and where delays are coming up, with any errors.

I would start by checking your client DNS points only to your DC, and your DNS service on the DC is forwarding DNS queries to your router/ISP - it sounds like your clients may be trying to locate their DC for authentication by first checking the Internet.

Originally Posted by latrosicarius

2.) I can't seem to be an administrator on my client PC with the user name that I log into the server with. I know this is possible b/c I am an administrator on my work client. Furthermore, at work, the HelpDesk has the ability to remotely grant me administrative privelages on my client PC (without physically comming to my PC). I'm wondering how to do this... maybe not remotely, but at least make me an admin on my own client.

I strongly recommend against having a regular user account being an administrator of local machines, this is one of the reasons viruses and worms are so prevalent and why Windows is perceived as insecure.
You should not need admin rights for day-to-day activity - if certain apps require it then launch them with a right-click and use "run as", then give the credentials of a local (not domain) admin user.

But basically, local groups (on the client machines) can have users or groups from the domain put into them - it sounds like your work's helpdesk have rights to modify the Administrators group on the client machines, and just add your domain user on the fly.
Bad practice.

[latrosicarius]

Originally Posted by Paul Adams

Okay, the thing with slow logons is you have to know where the delay occurs.
What I mean is the logon process from entering your credentials to having your desktop up has some key points in it - you need to describe a) where the delay occurs and b) how long it is.

1. You initially enter your credentials and the window greys out the input boxes
2. The logon window vanishes and the first status window appears
3. "Applying your user settings" (or similar, I forget the exact text) appears
4. Any logon scripts from group policies are executed
5. Any post-logon scripts on the local machine are executed
6. Your desktop is up and you are logged in

You might want to look into "userenv logging" to check the logon process and where delays are coming up, with any errors.

I would start by checking your client DNS points only to your DC, and your DNS service on the DC is forwarding DNS queries to your router/ISP - it sounds like your clients may be trying to locate their DC for authentication by first checking the Internet.

You, my friend, are a genius. That was exactly the problem (it was hanging on "Applying your user settings"). I assume, it was checking out on the Internet for a domain with my domain name, and when it could not find one, it would eventually come across the internal network domain.

Well, I went into START > CONTROL PANEL > NETWORK CONNECTIONS > right-click on LOCAL AREA CONNECTION > select PROPERTIES in the dropdown list.

Then select INTERNET PROTOCOL (TCP/IP) from the list > click PROPERTIES > ADVANCED > click on the DNS tab.

Then, in the "DNS server addresses, in order of use:" box, click ADD and type in my server's IP address, which I had already staticed, both on the server itself, and in the router. (If this helps anyone else, read down to the bottom of this post, where I'll show you how to make your server's IP address static (internally to the LAN, obviously--to get a static IP for your router itself, you need to upgrade your Internet service from your ISP to a commercial line).)

Anyway, now it logs in almost instantly! Thanks!

Originally Posted by Paul Adams

I strongly recommend against having a regular user account being an administrator of local machines, this is one of the reasons viruses and worms are so prevalent and why Windows is perceived as insecure.
You should not need admin rights for day-to-day activity - if certain apps require it then launch them with a right-click and use "run as", then give the credentials of a local (not domain) admin user.

But basically, local groups (on the client machines) can have users or groups from the domain put into them - it sounds like your work's helpdesk have rights to modify the Administrators group on the client machines, and just add your domain user on the fly.
Bad practice.

Hmm, I see what you're talking about. If a virus gets control of a user account, it will only have restricted rights, but if it gets control of an Administrator account, it will have full privelages to muck up the whole system.

I actually already found out how to make my account an Administrator before I checked your post. What I did was, log into the server domain from the client PC like normal. Then go to START > CONTROL PANEL > USER ACCOUNTS.

Now, at this point, it was a shock b/c the normal User Accounts screen had been replaced with more of a properties-page dialog interface. Anyway, there was a list called "Users for this Computer", and inside it was listed the Administrator account, the ASPNET account that gets installed when you DL the .NET Framework, and the Guest account, but not my account.

So I clicked the ADD button. It prompted for the Administrator's password so I entered it (by the way, this WILL NOT work if you have previously left your Administrator account's password blank... if that is the case, you need to log out, get into your Administrator account, and change the password... then come back). Well, lo and behold, it was a snap to just add my user name and domain; next time I logged in to the domain as usual, I was happily supprised to find myself with all Administrative privelages...

*Happy*, that is, until I read your post. I've since returned myself to a restricted User account to be more safety-minded.

I just want to say THANK YOU to everyone who helped, especially to Paul!

----------

Now, as I mentioned above, this is just for those who want to know how to "static-ize" your server's IP address, both in the server itself, and in the router.

Doing it in the server is easy, just click START > CONTROL PANEL > NETWORK CONNECTIONS > right-click on LOCAL AREA CONNECTION > select PROPERTIES in the dropdown list.

Then select INTERNET PROTOCOL (TCP/IP) from the list > click PROPERTIES. There is an option to (1) "Obtain and IP address automatically", or (2) to "Use the following IP address". Well click on the second option and... put this window to the side....

Click START > RUN > type "cmd" and press ENTER. In the DOS box, type "ipconfig" and press ENTER. You will see three numbers listed: your current "IP address", as was assigned by the router, your "subnet mask", and your "default gateway", which is your router itself.

Just copy down those three numbers and bring back up the other window that you put off to the side just a second ago. You will notice, that it also has three boxes for you to input the three numbers you just wrote down. Do so, and press OK.

Now, we must go into the router. To do this, go to Internet Explorer or Firefox, and in the address bar, enter the "default gateway" number that you just wrote down (which will typically be "192.168.0.1"). It is the IP of your router. Your router configuration page will open in your browser.

This part gets tricky b/c every router company sets the configuration page up differently, and you will probably have to go to their respective websites and find what their default password is... otherwise, you won't be able to enter the configuration page.

You are looking for a feature called "DHCP". There should be a section that says "Add Static DHCP Client", and it will list the IP addresses and MAC addresses of all the computers currently attached to it (either directly or through switches, hubs, etc.).

The general process is to find your server in the list, enter it's IP address (that you previously wrote down, in case the router rebooted and tried to assign it a different IP by now). You will also need to enter it's MAC address and optionally name it "Server", etc. Just save your settings and there you go--both your server and router have assigned a static IP to your server. As, I said before, this does not mean that your router itself, is getting a static IP from your ISP, it just means that INTERNALLY, whithin the LAN, your server will always have the same IP.