Cannot scan to shared folder using canon IR copier

The case:

We have a corporate Canon IR copier with scan over network feature enabled. But we cannot scan to the shared folder at the smb server.

Carnet_adresses_modif

So, lets find why.

At the beginning I suspected a permission issue on the share, so I checked the permissions that seems correct, everyone is given read and write acces to the share.

Second, I started process monitor on the computer who hosts the share, but it did not give me any clue. So I deduced that the issue is related to the network and I have to do a captue the packets on the Canon’s Ethernet interface.

To do so, I set up the SPAN (Switch Port Analyzer) feature on the Cisco Catalyst Switch to copy all the network trafic from the Canon’s interface to another interface on which I plugged a PC with Wireshark installed on it.

Here is the wireshark’s capture result:

Wireshark_netbios_issue_modif

We can see the canon copier sending Netbios broadcasts asking for the IP address of the host named AL1XXXX7P (The smb server). As it didn’t receive any response he sends a dns query to the DNS Server asking for the IP of the AL1XXXX7P.DOMAIN.LOCAL host, and the DNS server replies with the IP 10.x.x.13.
Next the copier sends a Netbios query to the 10.x.x.13 host trying to initiate a communication on UDP port 137. the smb server replies that he can’t communicate on port 137.

Ok, now we know why the scanned documents are not sent to the the smb share. So Why the SMB server cannot use his UDP 137 port?

The reason is that, a few days ago, I’ve enabled the “Disable Netbios over TCP/IP” option of the network interface. By enabling Netbios over TCP/IP again I was able to send scans again from the Canon copier to the SMB Server.

NIC_Netbios_disabled

In the following screenshot the Wireshark trace when the the Netbios communication betwen the two devices succeed:

Wireshark_netbios_success_modif

Case of unexplained LDAP requests

In this post I will explaine how I troubleshooted an unusual LDAP requests on the network.

The case:

A computer member of windows domain is sending LDAP requests massively and constantly on the network, to all the domain controllers of all sites.

The computer is on site A (Subunet 192.168.1.0/24) and sends UDP packets on port 389 to the domain controllers located on the following sites:

– B (subnet: 192.168.2.0/24)

– C (Subnet: 192.168.3.0/24)

– D (Subnet: 192.168.4.0/24)

The requests appears on the entreprise Firewall, and the IT manager of one of the remote sites, starts complaining about this unusual udp packets sends to his domain controllers. So I decided to find out what is causing these massive LDAP requests.

Kerio_ldap_modif

The investigation:

In the firewall, I’ve terminated all the UDP requests on port 389 (LDAP) initiated by the host 192.168.1.89. I started Process Monitor (procmon) and waited untill the host starts sending UDP packets to the domain controllers. After that I stopped the procmon’s capture and started my investigation.

The big question was: which process is sending this LDAP requests? And why is it doing it?

So in process monitor, I set a filter on the Path column that contain 389 value.

Filter_path_389

The result of applying the filter is the following:

NB: for confidentiality reasons I hid the original IP addresses and assume that subnets are 192.168.x.x

Filter_path_389_result1

We can notice that the “Lsass.exe” process is sending UDP requests on port 389 to the local and remote domaine controllers.

What is lsass.exe process in fact? Lsass.exe for Local Security Authority Sbsystem is a process in Microsoft Windows operating systems that is responsible for enforcing the security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens. It also writes to the Windows Security Log (https://en.wikipedia.org/wiki/Local_Security_Authority_Subsystem_Service).

So now we have to find which process is calling lsass.exe to authenticate on the domain controllers?

The answer is found upon above in the trace.

lsaas_read_sophos_regkey

The lsass.exe process is accessing a registry key “SophosSAUALGUCT120000” which is in fact the concatenation of “SophosSAU” for Sophos Antivirus Update program and the netbios name of the Windows PC.

Having this clue between hands, I stopped the Sophos Update service from service manger and observe if there is any LDAP request sent. And there was no LDAP query sent for a while. But when I start the Sophos Update Service the LDAP reapprars quickly.

The culprit was found, but what was causing Sophos Update Service sending this unusual LDAP requests? After having a deep look to the sophos installation in the PC it revealed the the installation was damaged. After reinstalling the Sophos antivirus again the problem was solved.

Conclusion:

Without tools like Process monitor, it would be difficult to troubleshoot this kind of issues.

You can download pocess monitor by clicking: https://technet.microsoft.com/en-us/sysinternals/bb842062.aspx

Troubleshoot access issue to a shared folder using Sysinternals tools

Introduction:

In this post I will show how to troubelshoot an access issue to a shared folder using Sysinternals tools.

The case:

In Symantec Backup Exec, I wanted to add a new storage device as a share. The shared folder was created in a Synology NAS, with domaine administrator rights including my username. But I got the following error: “The path seems to be invalide. Check the server and the paths names”.

Chemain inaccessible_modif

So I tried to access the shared folder with Windows Explorer…and it works!

Nas_Share_From_Explorer

So why Symantec BE is unable to access this share?

To discover it, I run Process Monitor and I take a trace when I clic on the Next button.

In process monitor I do a search on the “\\NASSYNOLOGY\Backup” string and the first result give me a clue. The process “BackupExecManagementService.exe” trying to access the “\\NASSYNOLOGY\Backupp” share is getting “ACCESS DENIED” as a result.

Procmon_access_denied_modif

The next step is to determine which user is running the BackupExecManagementService.exe process. To do so, I use the SysInternals’ Process Explorer tool.

In process Explorer, right clic on BackupExecManagementService.exe, then clic on properties and then on Security tab to get the user name who ran this process.

ProcExp_BE_access_user_modif

Effectively this user were not granted the access rights on the shared folder. By giving it the correct access rights the problem was solved.

You can dowload the Sysinternals suite here: https://technet.microsoft.com/en-us/sysinternals/bb842062.aspx