02:17:48 PM
3KC0UN6V4
I have asked FiC why they started with 4.x, and I still do not know.
All my servers are w2003 32 bit latest version with anywhere from 4-32 Gig RAM. Somebody suggested to me that I should ask you if you thought the fact that the servers also have locally connected users and shares might be an issue. IOW website XYX is mapped to c:\sites\xyz, but c:\sites is also a local share called MySites that a network user could map a drive to.
A related question: my WC license came with both 4 and 5. I have to use 4 for FiC. If I also at the same time have a straight WC site running on 5, IOW using both versions simultaneously, is that allowed under the license agreement?
Thanks
Tuvia,
First off you're using an at least 7 year old version of wc.dll if you're using a 4.x based version. Lots has been changed and fixed since then. :-) While I understand that's a requirement for FIC that's a long stretch for me to check into, and I can't help but think that FIC made a bad decision in sticking with the 4.x version when they created FIC when 5.x was already avalailable for some time - they basically locked themselves out of any upgrades and fixes that we provide for both the core and framework.
Ok, so I have not seen any of the behavior you describe nor have I ever heard complaint from anyone else about this - that doesn't mean it's not real, but it does seem to suggest something out f the ordinary is happening on your setup. If you can provide me with repro steps that I can check out on my end I'll be happy to take a look and fix it if there is a problem in a recent version of Web Connection.
What I do know is that there are multiple auth schemes involved (Windows Auth for the main admin page, and Basic for Web Connection Requests) for admin authentication, which can cause at least two logins. But once you're logged in either of these auth schemes should stick unless you're doing some crazy stuff in multiple browser windows.
+++ Rick ---
1. Frequently calling any management function from wc.dll gives an invalid admin account error for no reason.
2. UpdateExe does not work (nor give an error - it pretends to work) on some sites. the only thing I can find in common within those sites is they have no anonymous user even listed under security.
3. Sometimes when accesiing a wc.dll management function from wc.dll I have to authenticate 2 or more times from one call.
4. Even if UpdateExe works on a site, neither it nor any wc.dll management call works when called propeprly from wwhttp.httpget.
5. If two or more administrators are listed in wc.ini, then sometimes no login will work (invalid login error) or the authenticated name is truncated by 1 character.
Well, if you don't know what it IIS Impersonation is, it's unlikely you set it :-) There's a setting in ApplicationHost.config that determines how the virtual handles authentication. Yes it's set in web.config or ApplicationHost.config but the latter is the main IIS configuration store.
>BTW, all the sites that use an app pool share the use of it via one user's login. So the only way to set the app pool user identity is to give it an admin level user. There is no way specify by site, just for the entire app pool no matter what site uses it. Using that as the main security user would be a disaster. IIS permissions for folders need to be coupled with server OS permissions for the site to work at all.
That's why you can create multiple app pools, so you can isolate each application. Not really sure why this matters though - if you have an admin account and that account really has full access to the system then it should just work. As should SYSTEM which is the Web Connection default.
> Basically I do not understand what it is you are trying to tell me.
Basically I do nto understand what it is that you're asking since you're telling me several issues that may or may not be related.
+++ Rick ---
+++ Rick ---
I was describing how it is working; I did not mean I thought it should work that way.
In the site security settings, I disable the "allow anonymous user" checkbox. I searched the help system and my friendly iis admin book and could find no reference to the setting you describe or even to the word impersonation except for asp.net, which we do not use.
BTW, all the sites that use an app pool share the use of it via one user's login. So the only way to set the app pool user identity is to give it an admin level user. There is no way specify by site, just for the entire app pool no matter what site uses it. Using that as the main security user would be a disaster. IIS permissions for folders need to be coupled with server OS permissions for the site to work at all.
Basically I do not understand what it is you are trying to tell me.
If there is an anonymous user in existance, even with rights only to a home non-wc page, then the app pool will run under local system. If there is no anomymous user, the apppool must have administrator level rights.
What? No.
If you don't want anonymous authentication to work turn it off in IIS. No matter what you do then no anonymous user will ever get passed through.
Based on what you're describing it sounds like you might have your IIS virtual or root configured to use Impersonation - rather than Application Pool based identity. With Impersonation the logged in user gets rights on the server (which is very, very bad!). Make sure you don't have this enabled in IIS - I don't recall how this gets set in IIS 6, but there's an option for it presumably on the security tab for the site/virtual.
+++ Rick ---
Thank you for the succint explanation. I think I understood that much, but it never works without more fiddling. The config console (at least in 4.x) seems to only create virtual or sub-sites, all my sites are top level sites in IIS.
Perhaps an example based on your description:
They break down like thi. the server has 20 sites all sharing one application pool. The app pool identity is set to local system.
now for site Site1:
dcom is set to an administrator level user.
OS does NOT have the anonymous user, I want anyone hitting the site to have to login.
Frankly, I think that last thing of no anonymous user is what is causng me many problems.
One thing that makes me think that, is that even if the dcom, iss, ad os are all set as administrators, the site will not run without SYSTEM having rights. BUT if I have an anonymous user that can hit the site main page at least, everything runs fine with no SYSTEM user and administrator rights.
Still, with all the admin rights, i often get invalid admin user account when doin things like re-read configuration. But sometimes not.
HOLD ON, just discovered the problem of the updateexe and some others, although still getting errors on some things like re-read config.
Here it is:
If there is an anonymous user in existance, even with rights only to a home non-wc page, then the app pool will run under local system. If there is no anomymous user, the apppool must have administrator level rights.
Tuvia,
The difficulty with configuration for Web Applications - and especially FoxPro Web Applications - comes from the fact that you have several different sets of permissions.
- IIS Permissions - typically the Application Pool Identity
- DCOM Permissions - If running in COM mode this determines the FoxPro permissions
- OS Permissions - Used for IIS ACL access in Virtual Folders
IIS Permissions
The most important of those tends to be the Application POol identity which affects all of the Web permissions that your application requires *before* it hits your FoxPro server. IOW, all file access that IIS needs, that wc.dll/WebConnectionModule.dll needs. This also affects the temp file path.
These permissions are set in the IIS Application Pool's Identity setting. Typically for WWWC app this should be SYSTEM, or a high rights Administrator account. Needs file read/write access to temp folder.
To check and see what account you're actually running under bring up the IIS Admin Page | ISAPI/Module Admin Page and look for the Server Account. That's the account the Application Pool runs under.
DCOM Permissions or FoxPro Execution Permissions
If you're running in COM mode your fox server's permissions are determined by DCOM Impersonation or if not set through passthrough permissions from the IIS Permissions. If you're running in File mode then the logged on account or whatever account launched the application determines the security of the FoxPro app. This account needs full access to all the data, possibly the registry, remote data sources or any other resources that your application code needs.
To find out what account your app runs under use Sys(0) and echo that back in a Process Method. If you've copied the wwMaint features Use the Quick View of Settings and look up Application User Account.
OS Permissions
There are several sets of OS permissions required to make your Web app work right. First and foremost the Anonymous user needs to be included in the file permissions for the Virtual/Root Web folder or else you get log in dialogs. The Application Pool user also should have rights in the virutal folder to read at the least and optionally write if you want to update settings in web.config/wc.ini dynamically through teh admin interface.
The other OS permissions are the temp folder which is important for file based processing - the temp folder needs to have rights for the Application Pool identity so that IIS/Web Connection can read/write temp files from the folder.
FWIW, all of this is automated as part of the Web Connection Configuration/Management Console. If you create a new project/process it'll set all of this up for you. If you have an existing site or need to configure a new site, the Configure Server Wizard will set most of these things for you.
+++ Rick ---
I have read the entire doc file and found it helpful. I have also been in this business for a long time, and have worked on some pretty complex IT installations worldwide in various platforms. Yet I find properly setting up a WC site, with correct security, to be the most confusing and difficult task in my entire career.
Perhaps I can be educated : My sites run on win2003, and each site only allows access to specific users from the server's local user list. No anonymous access allowed even to index.html. There is an administrative user who has admin rights to all sites.
So let's say I have site MySite:
SiteFolder
-- bin folder wit wc.dll/ini
appfolder
myapp.exe is here
-- subfolders with data, etc.
-- the temp folder is also under here
upateFolder
this folder just holds the new exe to be used in updateexe
Let's call the allowed user MyUser. I have given Myuser rights to all the above folders (the admin usre has rights as well, thus 2 users with rights). In IIS I have also given site permission for that same user and of course the admin.
In wc.ini I list as the adminaccount the admin user. I tried adding Myuser as well, but all wc.dll admin functions fail if I do that.
Site and apppool setup OK, windows and basic authentication turned on. Scriptmap set.
The wc site setup can never register the exe itself, so I set up the site manually.
Now comes the tricky part.
1. What IIS permissons, if any, should system, network service, and local service have? To which folders?
2. What server file permissions should those same accounts have and to which folders?
3. In dcomcnfg, I have eveything for the exe set to default except the user under which the exe runs. I have set that to Myuser, the only setting I found to work. What should I be doing in dcomcnfg?
4. In the wc setup it offers to give dcom rights to multiple users. Do I need to do that and where?
5. When I use admin.asp and I do a function, I often get 3-5 prompts for user authentication before the process runs. Each time I am entering the same user. What did I do wrong?
6. How does the impersonation setting in wc.ini fit into any of this?
your kind advice is appreciated.