Friday 22 October 2010

Yet another possible reason for error of sending SMS with GPRS Modem

In Deepnet, some users still got the notorious error message "org.apache.xmlrpc.XmlRpcException: null values not supported by XML-RPC" when they tried to send SMS with a GPRS Modem.


Coincidentally, this problem happened on my Motorola which can be taken as a GPRS Modem. On the second day, I received a message from T-Mobile, my network operator. It says "Yesterday you sent a message to an invalid number. UK mobile numbers start with 07 or +447. Numbers starting 447 without the leading + are invalid."


Immediately I realized the mobile number format requested was the culprit. In deepnet, mobile number must comply with the so-called "International Format". Assume you have a UK SIM card, and the mobile phone number is given as 07955512345, in deepnet you have to use 00447955512345, which is correct when you use SMS service provider like Clickatell, however it is wrong for Mobile Operator, at least in my case.


In that case, you have to do some modification so that this kind of phone number format is allowed in Deepnet. Please follow the instructions below.



1, go to the folder “C:\Program Files\Deepnet Authentication Server\Tomcat\webapps\das\scripts”, assume you have installed the server in the default folder;
2, backup the file “admin.js”, then open it with your favourite editor;
3, locate the function “isValidMobile”

function isValidMobile(sMobile) {
// var mobileExp = /^[0]{2}\d{1,}$/;
var mobileExp = /^\d{1,}$/;
return mobileExp.test(sMobile);
}

4, change it to

function isValidMobile(sMobile) {
return true;
}

5, try to modify the mobile number to “+447955512345”;
6, send SMS OTP;

Monday 18 October 2010

RRAS on Windows 2008 R2

I always use MS remote access server(in Routing and Remote Access, RRAS) to test a simple VPN connection. Running and connection RRAS on Windows 2003 is very straightforward, however the connection to RRAS on Windows 2008 R2 never succeeded



If I selected "PPTP VPN" as the type of VPN



The connection attempt failed immediately with Error Code 678.



With this symptom, I soon realized that, unlike on Windows 2003, WAN Miniport(PPTP) must be configured manually on Windows 2008.


Open RRAS which is installed by adding a server role called "Network Policy and Access Services" on Windows 2008. Select "Ports" at left pane, you will notice there is only one "WAN Miniport(PPPOE)" configured(at right pane).



Right click "Ports", then select "Properties", you get



In devices list, select "WAN Miniport(PPTP)", then click "Configure..." button,


At least check the option "Remote access connections(inbound only)"



Now you can see there are a few WAN Miniports(PPTP) waiting to be connected!

Friday 8 October 2010

Backup Deepnet Server(vension 3.x)

Deepnet Authentication Server(DAS) saves its main configuration and almost all of its operation data in a database, so please check the offical document from MS(if you are using MS SQL server) or MySQL(otherwise) for SQL Backup.


For disaster recovery, you should also backup the DAS server itslef. There are two scenarios


Full Backup




  • Stop DAS service (net stop das);
  • Stop MySQL service (net stop dasmysql) if you chosed the built-in MySQL as its database.
  • Buckup the whole things under the folder "C:\Program Files\Deepnet Authentication Server"

Once backup is finished, start MySQL(if it is stopped) and DAS service.


Essential Backup


Compared to the full backup, the essential backup is trivial, but much smaller.


The following files and folders should be selected during this kind of backup


Files


  • server.xml under C:\Program Files\Deepnet Authentication Server\Tomcat\conf
  • keystore under C:\Program Files\Deepnet Authentication Server


Folders


  • conf under C:\Program Files\Deepnet Authentication Server
  • licence under C:\Program Files\Deepnet Authentication Server
  • dgs under C:\Program Files\Deepnet Authentication Server\Tomcat\conf

Thursday 7 October 2010

Mystery of sending SMS in Deepnet with GPRS modem

Some of Deepnet Security customers who use GPRS Modem to send SMS reported they sometimes got the error "org.apache.xmlrpc.XmlRpcException: null values not supported by XML-RPC"



As far as I was concerned, this error message created a misleading impression.


Fortunately, you can check the actual reason by looking at the related log file,dgs.log, which by default is located under the folder C:\Program Files\Deepnet Authentication Server\Tomcat\logs


In my case(I am using GPRS609 Modem), I got the following


INFO 2010-10-07 12:00:09,109 DGS - Got Transport: GSMModem, Provider: GSM Modem, Service: SMS
INFO 2010-10-07 12:00:09,125 DGS - SetParameterValuesTransportFilter
ERROR 2010-10-07 12:02:03,906 org.smslib - GSM: Network registration denied!
ERROR 2010-10-07 12:02:03,921 DGS -
com.deepnet.dgs.common.exception.DGSException: GSM Network Registration denied!
at com.deepnet.dgs.providers.GSMModemTransport.send(GSMModemTransport.java:41)
at com.deepnet.dgs.services.TransportFilterChain.send(TransportFilterChain.java:26)
at com.deepnet.dgs.services.SetParameterValuesTransportFilter.send(SetParameterValuesTransportFilter.java:10)
at com.deepnet.dgs.services.TransportFilterChain.send(TransportFilterChain.java:24)
at com.deepnet.dgs.services.Communicator.sendSMS(Communicator.java:46)
at com.deepnet.dgs.services.Communicator.sendMessage(Communicator.java:64)
at com.deepnet.dgs.services.Communicator.send(Communicator.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.xmlrpc.Invoker.execute(Invoker.java:130)
at org.apache.xmlrpc.XmlRpcWorker.invokeHandler(XmlRpcWorker.java:84)
at org.apache.xmlrpc.XmlRpcWorker.execute(XmlRpcWorker.java:146)
at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:139)
at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:114)
at com.deepnet.dgs.servlets.DgsXmlRpcServlet.doPost(DgsXmlRpcServlet.java:97)

...........

Now you have a better vision of this problem - "GSM Network Registration denied". You may ask why, well, I think it is a challenge to Deepnet support team, as Deepnet system only deals with 2 important setings, COM Port and Speed (the other two are descriptive names), they are nothing to do with GSM Network Registration!


With a revised dgs.war provided by Deepnet Security Ltd, I saw something really interesting in the log file.




INFO 2010-10-07 11:38:01,390 DGS - Got Transport: GSMModem, Provider: GSM Modem, Service: SMS
INFO 2010-10-07 11:38:01,421 DGS - SetParameterValuesTransportFilter
WARN 2010-10-07 11:38:25,281 org.smslib - CMS Errors [ +CMSERROR:33555 ]: Retrying...
WARN 2010-10-07 11:39:11,140 org.smslib - CMS Errors [ +CMSERROR:332 ]: Retrying...
WARN 2010-10-07 11:39:21,281 org.smslib - CMS Errors [ +CMSERROR:33571 ]: Retrying...
WARN 2010-10-07 11:39:43,390 org.smslib - CMS Errors [ +CMSERROR:33571 ]: Retrying...
ERROR 2010-10-07 11:39:57,796 org.smslib - CMS Errors [ +CMSERROR:33555 ]: Quit retrying, message lost...



if you'd like to carry out the same experiment, please download the file dgs.war and upgrade your Deepnet server at your own risk! Upgrade instructions are listed below.


At this stage, you are adviced to check the error code in GSM specs. For your convenience, you can get it from here.


Want a futher investigation? you are encouraged to use HyperTerminal to test SMS. For details, please look at this page where the essential AT commands are described, you can also find these AT command descriptions in my favourite PDF file How To Configure A GSM Modem Using HyperTerminal.


Upgrade Instruction




  • Stop DAS service, in Command Prompt, type "net stop das";
  • Delete all log files under the folder "C:\Program Files\Deepnet Authentication Server\Tomcat\logs", assume you have a default installation of Deepnet Authentication Server;
  • Delete the subfolder DGSSERVICE under "C:\Program Files\Deepnet Authentication Server\Tomcat\work";
  • Backup the file dgs.war under "C:\Program Files\Deepnet Authentication Server\Tomcat\dgswebapps";
  • Delete everything under "C:\Program Files\Deepnet Authentication Server\Tomcat\dgswebapps";
  • Copy the revised dgs.war to "C:\Program Files\Deepnet Authentication Server\Tomcat\dgswebapps";
  • Start DAS service(type "net start das" in Command Prompt);


Reference


CMS ERROR Code List

Wednesday 6 October 2010

LDAP Bind Account Requirements


Some organizations may wish to use a specific user account(other than the administrator) for the Bind process, it is important to ensure that the Bind DN account has the correct level of permissions on the LDAP directory.



When creating an application in deepnet where you can import users from a LDAP server, a user account must be defined for connecting to the LDAP directory. This account is known as the Bind Distinguished Name (DN) and the process of connecting to the LDAP directory is known as Binding. In theory, this account can be just a simple authenticated user who has permissions all over the place to read(by default). During the Bind process, the Bind DN account is used to search for the user account that is attempting to authenticate to Deepnet Authentication Server. The Bind DN must also be configured with the account’s correct password or Bind DN Password.



In the example below, a Bind DN account named CN=ed binden,CN=users,DC=nanoart,DC=local will be used to connect to a LDAP directory’s Base DN of DC=nanoart, DC=local.




At a minimum, the Bind DN account must have:

    • Read access to the user objects in the LDAP directory in order to search for user accounts

    • Read access to the Base DN (for example, DC=nanoart, DC=local) with the correct attribute that is used as the LDAP Login Name
    (for example, samAccountName)


Generally, we use ADSI Edit to check the security




In order to do Group Extraction, which is the process of determining a user’s group membership and returning those values to Deepnet Authentication Server, the Bind DN account must also have:

    • Read access to the group attributes in the LDAP directory

In order to support password expiration during authentication, the Bind DN account must also have:
    • Read access to the PwdLastSet, UserAccountControl, and msDS-User-Account-Control-Computed attributes in the LDAP directory

In order to use an alternative Single Sign On attribute (SSO Name Attribute), such as UPN format, the Bind DN account must also have:
    • Read access to the particular SSO Name Attribute of interest in the LDAP directory


Finally, I'd like to point out, you can even configure Active Directory to allow anonymous queries, you may have a look at Q320528 and Anonymous LDAP operations in Windows 2003 AD.

Monday 4 October 2010

Disable RDP credential prompt


Remote Desktop Connection on Windows 7(Vista as well) prompts you for credentials before you establish a remote desktop connection to Windows 2008.

As a result, it bypasses the remote machine's logon screen. This may be convenient if you save the credentials(username/password), next time, you don't need to input the credentials again. However, it brings a big trouble to the Deepnet users who are using its Terminal Server agent, because there is no chance to input the OTP in the prompt.



In order to show the login screen(Credential Provider) of the remote machine,




Login Screen Without Deepnet



Login Screen With Deepnet


you have to disable the credential prompt of RDP 6.0 client, which is achieved by editing the Default.RDP file in notepad to include enablecredsspsupport:i:0 and make it read as


....
authentication level:i:0
enablecredsspsupport:i:0
....

Note: the original authentication level is 2(authentication level:i:2).

Please look at KB941641 for the details.



If you save the Default.rdp file at default location "Libraries\Documents"(physically at the folder "C:\Users\userXXX\Documents"), please change the view setting in Folder Options to show it. as this file is a hidden file.



Reference

Remote Desktop Connection 6.0 prompts you for credentials before you establish a remote desktop connection

Saturday 2 October 2010

Application crash dump in Windows 7

I am so familiar with Dr Waston in XP that I thought I could also use it in Windows 7 as a postmortem debugger to get application crash dump. However, I got the following when I tried to run it to do setup by typing "drwatson.exe"



Accoding to google search results, Dr Watson is no longer used since Windows Vista, it has been replaced by "Windows Error Reporting"(WER) which is located at C:\Users\USERNAME\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_crashtest.exe_UUID. For me, the content of WER is useless though.
If you check this sample, you may agree with me.



Fortunately, you can still get the crash dump file if you follow the instruction mentioned by KB931673.



This feature is not enabled by default. Enabling the feature requires administrator privileges. To save these user mode memory dumps locally using Windows Error Reporting, create the following Registry key:




HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
Value Name = DumpType
Data type: REG_DWORD
Value Data = 1

Data Values Descriptions:
0 = Create a custom dump
1 = Mini dump
2 = Full dump





The crash dump file is generally stored at the folder "“%LOCALAPPDATA%\CrashDumps"



If the crashing process is a service, the location may be at

C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps



Open the crash dump file with WinDbg, and enter the command "!analyze -v", it can tell you where the problem is. With my example, it happened at




> 154: *pEmpty = 'x';




0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************


FAULTING_IP:
crashtest!WndProc+94 [c:\projects\crashtest\crashtest.cpp @ 154]
01331224 c60078 mov byte ptr [eax],78h

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 01331224 (crashtest!WndProc+0x00000094)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000000
Attempt to write to address 00000000

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

PROCESS_NAME: crashtest.exe

FAULTING_MODULE: 76ee0000 ntdll

DEBUG_FLR_IMAGE_TIMESTAMP: 4ca4a81d

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 00000001

EXCEPTION_PARAMETER2: 00000000

WRITE_ADDRESS: 00000000

FOLLOWUP_IP:
crashtest!WndProc+94 [c:\projects\crashtest\crashtest.cpp @ 154]
01331224 c60078 mov byte ptr [eax],78h

FAULTING_THREAD: 000009ec

PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS

BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS

LAST_CONTROL_TRANSFER: from 76c786ef to 01331224

STACK_TEXT:
0031f6e0 76c786ef 001d0222 00000111 00008003 crashtest!WndProc+0x94 [c:\projects\crashtest\crashtest.cpp @ 154]
WARNING: Stack unwind information not available. Following frames may be wrong.
0031f70c 76c78876 01331190 001d0222 00000111 user32+0x186ef
0031f784 76c789b5 00000000 01331190 001d0222 user32+0x18876
0031f7e4 76c78e9c 01331190 00000000 76c7910f user32+0x189b5
0031f7f4 013310d3 0031f810 0031f8b8 00000001 user32+0x18e9c
0031f81c 005e8dcf 000000f3 00000119 01331456 crashtest!wWinMain+0xd3 [c:\projects\crashtest\crashtest.cpp @ 51]
0031f830 00000000 004b1654 00000001 b6d37f1e 0x5e8dcf


STACK_COMMAND: ~0s; .ecxr ; kb

FAULTING_SOURCE_CODE:
150: break;
151: case ID_FILE_CRASH:
152: {
153: char* pEmpty = NULL;
> 154: *pEmpty = 'x';
155: }
156: break;
157: case IDM_EXIT:
158: DestroyWindow(hWnd);
159: break;


SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: crashtest!WndProc+94

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: crashtest

IMAGE_NAME: crashtest.exe

BUCKET_ID: WRONG_SYMBOLS

FAILURE_BUCKET_ID: WRONG_SYMBOLS_c0000005_crashtest.exe!base_address

Followup: MachineOwner
---------




If you just want to know the fault address(offset), you can check it from Control Panel -> Action Center





A little bit bizzare though, I couldn't reach the problem reports by a few clicks, it sounds no link in Action Center to get there, so that I had to search it




Double click one in the problem history, you can see Exception Code, Offset and other information.







Reference


How to create a user-mode process dump file in Windows Vista and in Windows 7