Anonymous DCOM Problems with remote Hyper V Manager(Access Denied. Unable to Establish Communication)



Running nismap.exe with –y parameter creates a map with "." instead of "_"


"nismap.exe" does not create the map name as expected when using the –y parameter. Below is an example of the attempt to use nismap.exe with –y to create the map named auto_home_svr_test:

 C:\temp>nismap.exe
create -i 1 -g " " -s localhost -f
"C:\Windows\IDMU\nis\nis2ad.log" -y auto_home_svr_test

Activity =
Creating map = 'auto.home_svr_test'...

 

SUCCESS

Creating

With further research, it was confirmed that this is a default behaviour of the nismap function.


Secondary GID not working with ADlookup


Recently we had a case where users from Windows 7, NFS client were unable to access the NFS share. Adlookup was set up properly. And changing the setting to fetch the information from Windows 2003, User name mapping server resolved the issue.

Note: We did not change any settings on the Unix NFS server

Current set up:

  • User name mapping configured on Windows 2003
  • NFS server configured on Windows 7/ windows 2008 R2/Windows 2003
  • AD configured and user's UIDNumber and GIDnumber populated.
  • On Unix the parent NFS share is own by user A and group A (permission 770)
  • Inside the parent NFS share, subfolders have user and group specific permission.
  • Windows user is not mapped to user A and group A but is mapped to the users who has full permission on the subfolder.

While troubleshooting we found that the windows user was getting access to the NFS share through secondary group membership, while using
User name mapping. But the same was not happening with ADlookup.

User name mapping feature was based more on Unix style and it allowed the NFS client to pass the auxiliary GID (secondary group) information to the NFS server. Hence when we are using User name mapping (which is fetching the information from NIS); we pass on the secondary group information. So, though the user A's primary group is X but still the user is able to get the access to the NFS share, since he is also a member of group Y.

On Windows 7\2008 R2, we have an option to fetch the mapping information from Windows 2003 (running user name mapping) and make this work.

But while using ADlookup, it will not pass the secondary group information to the NFS server and hence the access fails for a folder
which has permission '770'.

Suggested options given in this scenario for ADlookup:

In case of ADlookup, we need to add the RX permission for others on the parent NFS share and give the appropriate permission on the sub
folder.


"Server for NFS" service exhibits different behaviour when restarted using different options


While working on a issue recently, we found that there was a difference in behaviour when we restart the "Server for NFS" service from the services console compare to restarting it using the "nfsadmin" command. The issue was happening after a disk was reformatted and could be reproduce if the Service was started from the services console. While if we start the service from the 'nfsadmin' command, the issue cannot be reproduced. 

Actually there are two pieces in the "server for NFS" architecture – the user mode service and the kernel mode driver. When we restart the services from the services console only one of the services gets restarted. When we use nfsadmin, it stops/starts both the kernel mode driver and user mode service. This is what is causing the difference.

You can also achieve the same by individually stopping the user mode service and driver using the net command instead of nfsadmin. You would need to run the command below:

  • net stop nfsservice
  • net stop nfsserver

 

When starting, you can just start nfsservice which automatically starts nfsserver.


Server for NFS (Windows 2008 R2) crashes as soon as the Clients mounts the NFS share


Recently we got an issue where the NFS server ( Windows 2008 R2 was hosting the NFS share) use to bugcheck as soon as the ESX client was mounting the share.

We found that the size of the NFS share was approximately 189 GB in size. The share was open to everyone and also was the only NFS export on the machine. Also the NFS and RPC drivers were updated as per the KB articles below:

· https://support.microsoft.com/kb/2485543    

· https://support.microsoft.com/kb/2662672   

 

We analyzed the dumps and found that the issue is due to the fact the NFS share is already mounted on another client. Ideally, when a share is mounted, on the server , we read the monitor file and notify the client holding locks. When the share is mounted for the first time, the monitor file will be empty. But in this case, it is not. We could see that the ._nfs\monitor got corrupted.

After some more probing we found that this system was running W2K3R2 earlier and the same volume was used to export NFS shares then as well. So it seems there is some problem related to memory/buffer allocations in the routine that reads/updates the monitor file.

Renaming the ._nfs on the volume in question resolved the issue and the bugcheck stopped.


Server for NIS service crashing at the startup


We recently got an issue where the Server for NIS service was crashing at a startup. In the environment, customer had added W2K8 R2 based DC and installed IDMU in his existing W2K3R2 based IDMU setup.

To begin with we tried checking if the numbers of available port are getting exhausted but that was not the issue. Then, took LDIF exports of NIS map for users and group and looked into it. Nothing seems to be wrong from the LDIF exports.

So to further troubleshoot on this, we collected the dumps while the Service was crashing. From the dumps it seemed that the issue was caused because of heap corruption. The dumps were also pointing to one of the user account which may be causing it.

So, we removed the Unix related attributed for this one user and Server for NIS service seems to be working fine. After collecting the LDIF output for this user again we noticed that the unixUserPassword holds two different values for this user.

To summarize the root casue: "A user in the AD was somehow populated with two different values for the unixUserPassword attribute which was causing heap corruption in the NIS service."

To resolve the issue" We removed the unwanted (default) value from the attribute and started Server for NIS.


Setgid/Setuid does not work against a NFS share hosted on Windows 2012


One of our customer recently reported issue where setgid/setuid was not working against a NFS share hosted on Windows 2012. Below are two images which shows the expected behaviour while SGID is set on a local share v/s the unexpected behaviour over a NFS share.

==> NFS Share

  ==> Local share

 

Through our investigation we could see that the behaviour with the setgid which is been observed is by design and in compliance with the NFS protocol. This is same for Microsoft Windows NFS Server (both v3 and v4.1). Per Windows NFS Server's design, newly created files will always be owned by the user/group that issued the CREATE request; in particular, it does not the owner, group, or mode bits of the parent directory into consideration creating the ACL for the newly created file, nor does the NFS specification require NFS servers to do so. There is an KB article https://support.microsoft.com/kb/951716

 

Inputs on the SafeSetUidGidBits registry:

 

The article https://technet.microsoft.com/en-us/library/cc731734.aspx talks about a registry key HKEY_Local_Machine\System\CurrentControlSet\Services\NfsSvr\Parameters\SafeSetUidGidBits = (DWORD)

  • A value of 1 causes safer setuid and setgid behavior.

  • A value of 0 causes the standard UNIX behavior.

 

The SafeSetUidGidBits controls whether the NFS Server will filter out the SetUID/SetGID bits from executable non-directory files when everybody or the file's group is granted write access to the file.

 

If a file is writable by somebody other than the file's owner, then somebody can replace the file with different contents.

If the file is executable by somebody other than the file's owner and the file has the SetUID bit set, executing the modified file contents will potentially execute the modified file with alternate user credentials, resulting as a potential elevation of privilege vulnerability.

 

As such, when SafeSetUidGidBits is enabled (the default), then NFS server will tell the NFS clients that the SetUID/SetGID mode bits aren't set so that any client executing the program will execute with the user's credentials rather than alternate credentials.


SUA-SDK, CSH crashes on Citrix XenApp system


We have got many issues reported for SUA SDK, where the korn/ C shell crashes.

While the C shell crashes just after launching the korn shell crashes as soon we run command like clear.

With further investigation, we had found that generally this is because of some anti-virus or Citrix software which inject some code into every process during start-up assuming them to be proper Win32 process. SUA processes we know behave a little different than other Windows processes especially during start up so this looks to be a feasible possibility.

Uninstalling XenApp citrix application does resolves the issue but this was not feasible solution on most of the scenarios.

Hence with further troubleshooting / research and investigation we noticed that there were two citrix drivers were interfering with SUA: rskcore.sys and ctxpidmn.sys

From the crash dumps we could see ctxpidmn.dll queuing which was coming from ctxpidmn.sys (Citrix driver pool allocation). To fix ctxpidmn.sys, follow the steps as per https://support.citrix.com/article/CTX132820               

  • Run regedit.

  • Add following registry key.

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ctxpidmn

    Type: String

    Name: UviProcessExcludes

    Value: csh ==>For C shell

  • Separate with colon if necessary for other commands. e.g.) vi;csh;yacc;clear

  • Reboot server to enable the setting.

 

Rskcore.sys, is a core part of Citrix Edgesight which is a monitoring agent for citrix. Unfortunately, there was no registry option or any other option available to exclude SUA processes and hence this driver needs to be removed.

 

With this the SUA works and users can launch C shell. Run the clear command from Korn shell. The steps discussed are based out of testing and alternate workaround.