gitmLosi
asked on
FTP Login using Domain Accounts
Ok, We got a Windows 2003 SBS server setup. Our client deals heavily with people who send them graphic files. They want us to setup an FTP location on their SBS server with a UserName and PW - not annoymous - that they can give to a client who needs to send something to them.
So far - we have everything setup. However, the problem is, the only way a user can login is by typing the domain name first (ie domain.local\ftpuser). This is not good, they should only have to type a username and password, not the whole domain name.
I found somewhere that using the admscript I can set a "defaultdomain" but that isn't helping even after I have restarted the Services.
Since there is no "local" accounts on an SBS server, and we can only create Domain accounts the username we setup is in the Active Directory, so how do we can the FTP service to query the domain database for user accounts, and authorize them access to get in?
Thanks!
So far - we have everything setup. However, the problem is, the only way a user can login is by typing the domain name first (ie domain.local\ftpuser). This is not good, they should only have to type a username and password, not the whole domain name.
I found somewhere that using the admscript I can set a "defaultdomain" but that isn't helping even after I have restarted the Services.
Since there is no "local" accounts on an SBS server, and we can only create Domain accounts the username we setup is in the Active Directory, so how do we can the FTP service to query the domain database for user accounts, and authorize them access to get in?
Thanks!
Have you looked at using - User Isolation mode? It will lock down the directories so they only see their folder as the root and cannot go anywhere else....you can even lock it down and use AD username/password. Post back if you need help configuring it.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/29753aec-35b7-4929-b0a5-846474f627ba.mspx
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/29753aec-35b7-4929-b0a5-846474f627ba.mspx
His issue isn't about isolating directories, users, etc. It's the fact that he's having to use the full domain\username format to login.
Matt
MSR Consulting
Matt
MSR Consulting
I know...I'm recommending that he use the "user isolation mode" method. Its safer, more secure and not too hard to configure. Installing FTP inside the network is a huge security risk and must be locked down as much as possible. You could use a thrid party FTP software though that would also give you some security options. (http://secureftp.glub.com/)
Huh? How would user isolation method solve his issue of not wanting to enter in the domain name as part of the username?
I'm not sure what you're comparing it too? For all we know he already is using "user isolation" since he never mentions otherwise. Just don't see the relevancy.
Matt
MSR Consulting
I'm not sure what you're comparing it too? For all we know he already is using "user isolation" since he never mentions otherwise. Just don't see the relevancy.
Matt
MSR Consulting
Hi gitmLosi,
I would HIGHLY recommend that you DON'T enable FTP on your SBS. It is a major security risk and will be difficult to manage the resources which it consumes.
Instead, I would recommend one of these options:
1. That you enable SharePoint as an Extranet which will easily allow an authenticated user to upload photos or other documents as defined by the document library you create. You'll find the complete how-to here: http://www.microsoft.com/technet/prodtechnol/sbs/2003/deploy/stssbs03.mspx
2. Use http://Groove.net -- This service's best feature is file sharing synchronization. All the client needs to do is put the images in a Groove shared folder on their computer and it will automatically synchronize that folder with a Groove shared folder at the company. Groove has recently been acquired by Microsoft and is being integrated into Office and SharePoint.
Jeff
TechSoEasy
I would HIGHLY recommend that you DON'T enable FTP on your SBS. It is a major security risk and will be difficult to manage the resources which it consumes.
Instead, I would recommend one of these options:
1. That you enable SharePoint as an Extranet which will easily allow an authenticated user to upload photos or other documents as defined by the document library you create. You'll find the complete how-to here: http://www.microsoft.com/technet/prodtechnol/sbs/2003/deploy/stssbs03.mspx
2. Use http://Groove.net -- This service's best feature is file sharing synchronization. All the client needs to do is put the images in a Groove shared folder on their computer and it will automatically synchronize that folder with a Groove shared folder at the company. Groove has recently been acquired by Microsoft and is being integrated into Office and SharePoint.
Jeff
TechSoEasy
ASKER
Guys, Thanks for the reply -
Matt - I hadn't thought of using the Realm option. We tried it though and it didn't have any effect on the FTP site. User Isolation mode didn't work either for some reason.
I do agree with Jeff - FTP should not be on an SBS server; however; this client has their mind set and we can't change it.
What we know so far - logging in to the FTP site requires the domain\username to be entered....we need a way to eliminate that and use just username.
Any other ideas?
Thanks!
Matt - I hadn't thought of using the Realm option. We tried it though and it didn't have any effect on the FTP site. User Isolation mode didn't work either for some reason.
I do agree with Jeff - FTP should not be on an SBS server; however; this client has their mind set and we can't change it.
What we know so far - logging in to the FTP site requires the domain\username to be entered....we need a way to eliminate that and use just username.
Any other ideas?
Thanks!
Just because the client has their mind set doesn't mean that you should allow them to compromise their security or even the entire usability of their server when you KNOW that it will do so. That's YOUR job to advise them of such things.
Creating a SharePoint extranet will protect them from these problems while making it MUCH EASIER for their clients to upload the pictures!!
Why don't you just try it and see, even without creating the extranet according to the article I provided, you can easily access their Sharepoint installation via https://server.domain.com:444 or if they don't use an external FQDN, https://ip.add.re.ss:444
Jeff
TechSoEasy
Creating a SharePoint extranet will protect them from these problems while making it MUCH EASIER for their clients to upload the pictures!!
Why don't you just try it and see, even without creating the extranet according to the article I provided, you can easily access their Sharepoint installation via https://server.domain.com:444 or if they don't use an external FQDN, https://ip.add.re.ss:444
Jeff
TechSoEasy
I'll setup ftp on my test sbs environment, never ran it from sbs. On my hosting servers though (which are Win 2003) I run MS Ftp server with hundreds of users, none of which require the full login format.
All I can think of is that it is somehow required when the ftp service is running on the domain controller itself.
Another thought though, how about using web folders/WebDAV instead of
FTP and they could just use their normal user experience of dealing with Windows Explorer style file manipulation.
Your best bet though if you absolutely must run an ftp server is to install a 3rd party ftp server, there are some good free ones even and using the 3rd party server would be more secure as you'd be using localized usernames only, not actual domain names.
I'll let you know the results of my ftp on sbs test.
Cheers,
Matt Ridings
MSR Consulting
All I can think of is that it is somehow required when the ftp service is running on the domain controller itself.
Another thought though, how about using web folders/WebDAV instead of
FTP and they could just use their normal user experience of dealing with Windows Explorer style file manipulation.
Your best bet though if you absolutely must run an ftp server is to install a 3rd party ftp server, there are some good free ones even and using the 3rd party server would be more secure as you'd be using localized usernames only, not actual domain names.
I'll let you know the results of my ftp on sbs test.
Cheers,
Matt Ridings
MSR Consulting
Before I setup my server can I just confirm how you used admscript? I know you said you had already done it, just want to make sure the format was correct.
Should be something like:
Adsutil Set MSFTPSVC/DefaultLogonDomai
Make sure when you type in the Domain Name that it is enclosed in quotation marks. The Adsutil vbs script should be in the inetpub\adminscripts directory.
Should be something like:
Adsutil Set MSFTPSVC/DefaultLogonDomai
Make sure when you type in the Domain Name that it is enclosed in quotation marks. The Adsutil vbs script should be in the inetpub\adminscripts directory.
By the way, if you do look at 3rd party servers I'd probably recommend Serv-U FTP Server (http://www.serv-u.com). They've been around forever and have a great reputation. I like them primarily because they support windows domains user database as a user source if you need it, as well as seemingly simple but important things like recognizing %user% variable.
It's cheap enough for one server that it really isn't an issue, but if you're looking for free I'd probably recommend GuildFTP.
Matt Ridings
MSR Consulting
It's cheap enough for one server that it really isn't an issue, but if you're looking for free I'd probably recommend GuildFTP.
Matt Ridings
MSR Consulting
ASKER
Matt -
Thanks for the comments - When I ran the admscript it was exactly as you put it above. I did put the domain in quotes. I'll be talking with the client tomorrow afternoon to recommend Sharepoint or Serv-U FTP. I think your right in the fact that the MS FTP is just becoming more of a hassle than it really worth.
I'll let you know the outcome afterwards.
Thanks for the comments - When I ran the admscript it was exactly as you put it above. I did put the domain in quotes. I'll be talking with the client tomorrow afternoon to recommend Sharepoint or Serv-U FTP. I think your right in the fact that the MS FTP is just becoming more of a hassle than it really worth.
I'll let you know the outcome afterwards.
ASKER
ok Guys - this is really beating me up....Here's the lastest -
Using MS FTP -
My computer and my tech's computer (both outside client network) can use both the DOS ftp client, and Windows Explorer to FTP into the client server (but we must type domain.local\username)
From client's home computer (also outside network) the Windows Explorer FTP does not work. DOS FTP not tested here.
From another computer outside network, DOS FTP works fine and Windows FTP doesn't work.
We gave up on MS FTP, and Installed Serv-U 30-day trial per Matt's recommendation:
DOS FTP works from all tested machines, both internally, and externally to the network.
Windows Explorer FTP does not work from any tested machines.
The benefit here is we don't need the domain name to login, but we can't get the Explorer FTP to work.
As for the FW - ports 20 and 21 are forwarded to the server.
Any ideas? I've increase the value on this question.
Thank you
Using MS FTP -
My computer and my tech's computer (both outside client network) can use both the DOS ftp client, and Windows Explorer to FTP into the client server (but we must type domain.local\username)
From client's home computer (also outside network) the Windows Explorer FTP does not work. DOS FTP not tested here.
From another computer outside network, DOS FTP works fine and Windows FTP doesn't work.
We gave up on MS FTP, and Installed Serv-U 30-day trial per Matt's recommendation:
DOS FTP works from all tested machines, both internally, and externally to the network.
Windows Explorer FTP does not work from any tested machines.
The benefit here is we don't need the domain name to login, but we can't get the Explorer FTP to work.
As for the FW - ports 20 and 21 are forwarded to the server.
Any ideas? I've increase the value on this question.
Thank you
>>"From client's home computer (also outside network) the Windows Explorer FTP does not work."
What do you mean by this? What is the EXACT error you are getting? Who is their ISP, and who is YOUR ISP?
It's really funny though, that you haven't even TESTED SharePoint for this... it's really VERY easy to use without any major configuration changes... just by using either Remote Web Workplace, or https://server.domain.com:444.
You can tell your client that this is a web based FTP, which essentially it is... it's just a different kind of File Transfer Protocol.
Jeff
TechSoEasy
What do you mean by this? What is the EXACT error you are getting? Who is their ISP, and who is YOUR ISP?
It's really funny though, that you haven't even TESTED SharePoint for this... it's really VERY easy to use without any major configuration changes... just by using either Remote Web Workplace, or https://server.domain.com:444.
You can tell your client that this is a web based FTP, which essentially it is... it's just a different kind of File Transfer Protocol.
Jeff
TechSoEasy
ASKER
Jeff -
The error is -
"An error occurred opening that folder on the FTP server. Make sure you have permissions to access that folder, details the operation timedout."
Event log shows the user was diconnected after 120 sec of inactivity.
We have looked at Sharepoint, and could not locate the folders to put the files. The client needs the files to be available from both the FTP site for authorized users and the windows computers in the domain through a network share.
As for the permission error, we are testing this using an Administrator account, and have fully verified all permissions.
The error is -
"An error occurred opening that folder on the FTP server. Make sure you have permissions to access that folder, details the operation timedout."
Event log shows the user was diconnected after 120 sec of inactivity.
We have looked at Sharepoint, and could not locate the folders to put the files. The client needs the files to be available from both the FTP site for authorized users and the windows computers in the domain through a network share.
As for the permission error, we are testing this using an Administrator account, and have fully verified all permissions.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Jeff,
I don't think anyone would disagree with you from a technical perspective. The challenge the client faces is that in the graphics world the de facto standard is command line ftp scripting for dumping and retrieving files. I can't imagine the client trying to get everyone they do business with to change the way they've always worked.
I think there were really only two options here for the client, a cheap second box configured to be the ftp server (best option) or sbs.
Many, if not most, tech folks are brought into small clients to 'execute' what they have already decided what they want, and not to be true 'consultants' or 'advisors'. You and I definitely see the world through the same lens, I'm just not sure our reality is everyone elses.
In other instances they are a 'consultant' and make early promises (like "absolutely this new sbs server will be able to be your ftp server for your business partners") that turn out to be not well thought out. Rightly or wrongly it would be difficult for that 'expert' to go back into the client and say, oops, now I need another computer because I was wrong about sbs. C'mon, we've all been faced with the 'eat crow or not do the ideal thing' scenario before.
Matt
MSR Consulting
I don't think anyone would disagree with you from a technical perspective. The challenge the client faces is that in the graphics world the de facto standard is command line ftp scripting for dumping and retrieving files. I can't imagine the client trying to get everyone they do business with to change the way they've always worked.
I think there were really only two options here for the client, a cheap second box configured to be the ftp server (best option) or sbs.
Many, if not most, tech folks are brought into small clients to 'execute' what they have already decided what they want, and not to be true 'consultants' or 'advisors'. You and I definitely see the world through the same lens, I'm just not sure our reality is everyone elses.
In other instances they are a 'consultant' and make early promises (like "absolutely this new sbs server will be able to be your ftp server for your business partners") that turn out to be not well thought out. Rightly or wrongly it would be difficult for that 'expert' to go back into the client and say, oops, now I need another computer because I was wrong about sbs. C'mon, we've all been faced with the 'eat crow or not do the ideal thing' scenario before.
Matt
MSR Consulting
If that's the case with the graphics industry, then I would definitely suggest that a separate FTP server be placed in a DMZ and that the SBS box NOT have this service. You can use a Windows XP Pro or Windows 2000 Pro machine for this purpose (or even a Unix box for that matter).
Aside from the security issue...allowing large graphic files to be uploaded directly to the SBS will probably cause it to lock up. There are already a lot of things going on in SBS... and the recommendation to keep FTP out of the mix is one that should be heeded.
Jeff
TechSoEasy
Aside from the security issue...allowing large graphic files to be uploaded directly to the SBS will probably cause it to lock up. There are already a lot of things going on in SBS... and the recommendation to keep FTP out of the mix is one that should be heeded.
Jeff
TechSoEasy
To enable Basic authentication and configure the realm name
1.
In IIS Manager, double-click the local computer; right-click the Web Sites folder, an individual Web site folder, a virtual directory, or a file; and then click Properties.
Note
Configuration settings made at the Web Sites level are inherited by all of the Web sites on the server. You can override inheritance by configuring the individual site or site element.
1.
Click the Directory Security or File Security tab, and then, in the Authentication and access control section, click Edit.
2.
In the Authenticated access section, select the Basic authentication check box.
3.
Because Basic authentication sends passwords over the network unencrypted, a dialog box appears, asking if you want to proceed. Click Yes to proceed.
4.
In the Default domain box, either type the domain name you want to use, or click Select to browse to a new default logon domain. If the Default domain box is filled in, the name is used as the default domain. If the Default domain box is left empty, IIS uses the domain of the computer that is running IIS as the default domain. IIS configures the value of the DefaultLogonDomain Metabase Property, which determines the default domain used to authenticate clients accessing your IIS server using Basic authentication. However, the domain specified by DefaultLogonDomain is used only when a client does not specify a domain in the logon dialog box that appears on the client computer.
5.
Optionally, you can enter a value in the Realm box, which configures the value of the Realm Metabase Property. If the Realm property is set, its value appears on the client's logon dialog box, when Basic authentication is used. The value of Realm is sent to the client for informational purposes only, and is not used to authenticate clients using Basic authentication.
6.
Click OK twice.
Matt
MSR Consulting