CODEWITHSUNDEEP
lotus-noteslotus-domino
Normunds Kalnberzins
Normunds Kalnberzins

Reputation: 1245

agent on domino server cannot see network drives

I know that the particular issue appears when you run Domino as a service that runs as local account or different user. However here I'm running it with user rights as a normal application. Then I start the agent from server console: tell amgr run etc.

I'm trying to enumerate available drives in two ways - as Filesystem roots using Java functionality and using Windows specific wmic. The relevant code is:

        System.out.println("os:"+System.getProperty("os.name") + " user:" + System.getProperty("user.name"));
        File[] roots = File.listRoots();
        for (File root : roots) {
            if (root.canWrite()) { 
                System.out.println("[rw] " + root.getPath());
            } else {
                System.out.println("[ro] " + root.getPath());
            }
        }
        Process process = Runtime.getRuntime().exec(
                new String[] { "wmic", "logicaldisk", "get",
                        "deviceid,volumename,volumeserialnumber" });
        process.getOutputStream().close();
        BufferedReader reader = new BufferedReader(
                new InputStreamReader(process.getInputStream()));
        String line = null;
        while ((line = reader.readLine()) != null) {
            System.out.println(line);
        }
        reader.close();

Running if from client (or simply from a standalone Java application) I get all drives:

os:Windows 7 user:normunds
[rw] C:\
[ro] D:\
[rw] N:\
[rw] W:\
DeviceID  VolumeName  VolumeSerialNumber  
C:        Acer        12857911            
D:                                        
N:        video       EE1C7944            
W:        DB_70       18389143

Where N: 'video' is a mapped share on network drive.

However when I'm running it on the server (same PC) I get only the local ones, not the remote smb drive:

19.11.2013 23:00:42   Agent Manager: Agent printing: os:Windows 7 user:normunds
19.11.2013 23:00:42   Agent Manager: Agent printing: [rw] C:\
19.11.2013 23:00:42   Agent Manager: Agent printing: [ro] D:\
19.11.2013 23:00:42   Agent Manager: Agent printing: [rw] W:\
19.11.2013 23:00:42   Agent Manager: Agent printing: DeviceID  VolumeName  VolumeSerialNumber  
19.11.2013 23:00:42   Agent Manager: Agent printing: C:        Acer        12857911            
19.11.2013 23:00:42   Agent Manager: Agent printing: D:                                        
19.11.2013 23:00:42   Agent Manager: Agent printing: W:        DB_70       18389143

Notice the user name, the code is running under my name; at least that's what Java thinks. I cannot figure out what causes the problem.

I even tried to write another version of this by calling Windows API method from LotusScript code: Declare Private Function GetLogicalDriveStrings Lib "kernel32" Alias "GetLogicalDriveStringsA" (Byval nBufferLength As Long, Byval lpBuffer As String) As Long with the same result - from client it works and returns all drives, on the server it misses. I guess one more step would be to ask Windows API the user name. Update: just did it, it also returns "normunds".

Any ideas of how to approach this issue?

Edited: What I think is happening is that Domino runs servertasks as separate processes impersonating the user that the server has been started with. In this way it closes down access to remote resources that would have been available if it ran servertasks with delegation level (of impersonation).

Now can this situation be changed by modifying some security policies or registry? As far as I understand network access in this situation happens as NullSession (anonymous user), so I assume one solution would be to enable share access by anonymous on remote end and allow NullSession to access this share locally. Edited: does not seem to help either :-/

Other, pretty wild solution, would be to log in from the agent using LogonUser Windows API to log in the same user again but with full rights (not sure if this is feasible and even if it is, imo it means to store somewhere username/password :-) And yes, it would limit us to the LotusScript solution, unless we want to install JNI wrapper; all this should actually sit in XPage (the agent is just an example of the problem)

Third solution would be to use UNC pathes instead of mapped drives and access the path with appropriate username/password (or anonymously + allowing NullSession access), but this solution kind of beats my purpose to discover the mapped drives and do this or that depending on which ones are available.

Upvotes: 0

Views: 2825

Answers (1)

Maurizio Benedetti
Maurizio Benedetti

Reputation: 3577

the problem is due to the way a network drive is mapped on a Windows Server. A background service cannot access a network drive by definition since the object is mapped at the moment of interactive logon.

Official Microsoft documentation:

http://support.microsoft.com/kb/180362

More information can be found here:

Map a network drive to be used by a service

I have developed several windows services in the past and this was a constraint to be kept under control.

I hope this helps in some way.

Cheers Maurizio

Upvotes: 1

Related Questions