Have an app on server ion. It calls a webservice on server2. Endpoint of that service is to write a pdf file on server3.
As a developer in dev on my laptop it works. As a deployed app it fails on the write.
IIS6, Windows 2003 servers as well as VS2008
AppPool Identity as network service will not write the file. If I use a "fake" user in AD the app pulls no data and fails to start up properly.
Any ideas?
TIA
My guess is that the credentials that are running the app on server2 does not have write permissions to server3 (assuming server2 uses a UNC path to write to the filesystem on server3).
The user account that runs the IIS Application Pool (or however credentials are assigned to your app(s)) on Server2 will need write access to the share/UNCpath on server3; generally this means you cant use NetworkService.
If you change the user account in IIS on server2, you'll need to take into account all the implied permissions that the existing user account (assuming NetworkService) has on server2.
Including Filesystem, Registry, Metabase, etc permissions; the list could be very long and complicated or short and irrelevant (depending on your implementation on servers1/server2/server3).
For all my implementations, we use AD User accounts that are designated as Service Accounts; with extremely limited permissions on the servers, each App would have its own Service Account, and any touch-points would require explicit permissions applied. Thus, an account would be setup for the app on Server2 and the explicit permissions would be configured on Server2 to run the app, and the UNC path/share and NTFS permissions on Server3 would be applied explicitly for the file transfer.
Hope this helps.
Related
Here's a simple example of my problem. I'm writing an application that self hosts a WCF service for communication only within the user's session. When multiple users run this application concurrently on a terminal services machine, all the users are happy as long as they don't have local admin rights. The problem begins if two or more users are admins, the 1st user creates the service, a 2nd user because the service has been created Globally...
Simple Win32 implementation, without WCF, would be create a named pipe with the "Local\" prefix. WCF appears to first attempt to create a global shared memory mapping, after that fails, then creates a local mapping.
Has anybody found a way to self host a WCF service that is local to the current user's session, even if the user is a local admin?
The easy way is just have each instance use a different service URL (deriving it from some characteristic of the user session to make it unique - e.g. session logon ID).
There's no way to stop the WCF binding publishing its endpoint details (aka the real pipe name) in the Global namespace if it's running with sufficient privileges to do so. But maybe you could adjust the process token privileges to disable the SeCreateGlobalPrivilege before opening the service host, if your service finds it is running as admin with elevated privileges.
using IIS 6
I have the default web site that works and can authenticate users to the domain when they connect.
I have created a second website, siteb, put a host (a) record into DNS, I can browse to it as long as I have use anonymous access, when I select windows authentication, it fails...
not sure what i'm missing here...
Thanks.
This goes beyond just IIS if you're using Integrated Windows Authentication. You've created "siteb" in DNS which allows your users to connect to it so this is good. However, when their browser requests a Kerberos ticket for "siteb" from Active Directory, AD is probably responding that it cannot find "siteb". You can verify this with Wireshark.
The fix is to add "siteb" (and any other permutations with which you expect users to access the site) as an additional servicePrincipalName for the server's machine account in AD. You can accomplish this with the "setspn.exe" utility. It should be available on your domain controller. If not, you can install it from the Windows 2003 Support Tools.
Some examples of adding a UPN alias with setspn on the DC are:
setspn.exe –A HTTP/siteb <server hostname>
setspn.exe –A HTTP/siteb.acme.com <server hostname>
This should take effect immediately. The final step is ensuring that the browser "trusts" the new website name. In Internet Explorer, for IWA to occur automatically, the server name should be listed in either the Trusted Sites or Intranet zone.
Of course, you could avoid all this hoopla by having the 2nd website just run on a different port under the same name, e.g.: http://sitea:81
I have this wierd problem on our Windows Server 2003, XP box running IIS 6.0. I have a WCF service deployed using an application pool identity. I am able to browse the svc file like this on that box,
http://localhost/servicename.svc
But when I do http://machinename/servicename.svc, it asks for credentials.
The website is configured for Anonymous access and Integrated Windows authentication.
I am really not sure what is wrong here, I have another machine that is a failover location for this box, where the same thing works fine with exactly same settings in IIS.
Make sure that the Application Pool identity has Read & Execute access on the files hosted by IIS (in other words, check the files at D:\path\to\site). Whether it's Network Service, a domain account, whatever.. it's going to need R&X permission.
What I'm guessing that's happening is that you're a local Admin on the server, so when you do it locally you're able to use your own local credentials to pull the site. But when you do it remotely, IIS must have access to these files - even if Anonymous access is enabled (otherwise, how can it load the files to serve the page to you?).
If you're still stumped, try using a program like filemon or procmon local on the server while making the request, and see what's getting Access Denied when you get a 401.
So I'm setting up a dedicated server using Debian 5 Lenny. I will be using some Atlassian Tools (JIRA, Confluence, Bamboo, and Fisheye). I want to use a local LDAP server to store information for the users that will be accessing these software titles, so that they can use one set of credentials to log in.
I also want webmail users to be configured using LDAP.
However, this is a small operation. Three people. That's why all of the software, including the ldap server, will all be on the same machine.
That said, is it safe to use LDAP to store user credentials (including passwords) in LDAP without using Kerberos? I'm confused as to when Kerberos should be used.
Hypothetically, let's say I had two servers on a subnet. Server A received requests from the outside world, for atlassian tools. Server a communicates to ldap server (internally) on server b. In that case, would I use kerberos?
When do I use Kerberos? When do I not?
I am not setting anything like "Active Directory" up. No Samba either. Users do not need to login to a domain (with access to files on the domain), they just need to login to webapps. But if I was doing LDAP on it's own dedicated machine, then I might want Kerberos?
:confuzzled: :(
-Sam
The simplest possible answer is yes, it is possible to store user names, user ids, and passwords without using Kerberos, and in fact directory services accessed via LDAP are an excellent tool for storing this sort of authentication and authorization information.
Update:
In my opinion, if you do choose an open source server, you will find OpenDS to be superior to OpenLDAP or Apache.
Basically, if you have Kerberos, you do not need any directory server. If you aren't in a corporate environment and are looking for an identity management store, you should definitively go for a directory server like OpenLDAP or Apache Directory. Kerberos require running a correctly set up DNS and NTP server. This might be way to much. Even if you do, those lazy morons from Atlassian still did not implement Kerberos support into their products. You can't even go with that.
I just noticed that there are only three of you, maybe a simple database setup with MySQL would suffice instead of running a full-blown directory server?
I have a WCF WSDualHttpBinding service. The service is contained in a WindowsService with account type LocalSystem.
The service is attempting to access a network file stored on another machine on the same network as the service, e.g. \\dataStoreMachine\\myshare\\fileToOpen.txt . If the service is running on dataStoreMachine (the same machine that stores the file), the file is opened succesfully. However, if the service is running on another machine in the network, the file is not found. Is this a permissions issue? I've given read permissions on the network share. Is there something that needs to be specified in the service bindings so it has the correct rights? The file can be browsed to from the machine running the service within win explorer, so I know the file is really at the location it's looking at it for.
Both machines on the network (a VMnet) are not on a specific domain, but have the same username, and blank passwords.
The LocalSystem account doesn't have any rights to network access. Assuming your servers are part of an ActiveDirectory domain, you should use the Network Service account to run the service. You'll need to give read permission for the share to the specific domain accounts assigned as the machine account of the servers. This is usually something like: YourDomain\MachineId123 where the MachineId123 is the actual machine name in the domain.
If you servers aren't in a domain, then you can use the synchronized passwords on identical local accounts technique. I would avoid this if at all possible because in the real world, it is very easily broken by a password change. Each server would have a local machine account named something like File123Shared and would have the same password as the same account on the other machines. You would run your service using that local account after configuring it to be able to run as a service and any other permissions it may need.