Quick basic configuration of a Cisco ASA firewall for custom IP address and ASDM access

Here are a few quick commands to wipe a Cisco ASA series firewall, resetting it to factory defaults, and then enabling the device for an IP address on your own subnet rather than the default 192.168.1.0/24, as well as setting up ASDM and telnet and ssh access. This gives you a very basic configuration from which you can access the device. First connect to the device via the console port and run the following commands to wipe the device:

ciscoasa> enable

ciscoasa# conf t

ciscoasa(config)# configure factory-default

Once the device has loaded the default configuration, disable DHCP on the inside interface to prevent the device dishing out IP addresses. This may not be relevant in your environment but in ours DHCP is provided elsewhere:

ciscoasa(config)# no dhcpd enable inside

ciscoasa(config)# no dhcpd address 192.168.1.5-192.168.1.254 inside

Set the ip address for the inside LAN on interface vlan1 if this is the vlan you are using for the inside network:

ciscoasa(config)# int vlan1

ciscoasa(config-if)# ip address 10.0.0.1 255.255.255.0

ciscoasa(config-if)# exit

Enable the http server, and allow access from the inside subnet

ciscoasa(config)# http server enable

ciscoasa(config)# http 10.0.0.0 255.255.255.0 inside

Configure the local AAA authentication database and create a new user account to log in to ASDM with:

ciscoasa(config)# aaa authentication http console LOCAL

ciscoasa(config)# username oasysadmin password Pa55word

Enable telnet and/or ssh on the inside interface if required:

ciscoasa(config)# telnet 10.0.0.0 255.255.255.0 inside

ciscoasa(config)# ssh 10.0.0.0 255.255.255.0 inside

ciscoasa(config)# aaa authentication ssh console LOCAL

Set the enable password

ciscoasa(config)# enable password Pa55word

Save the configuration and reload

ciscoasa(config)# write mem

ciscoasa(config)# exit

ciscoasa# reload

Advertisements

Citrix Error: Event ID 1004 “faulting application XTE.exe, version 4.5.0.64631”

The other day I installed the Citrix Hotfix Rollup PSE450W2K3R07 on one of our Citrix servers. Shortly after this I was alerted to an issue where sessions were disconnected, so I checked the event log and noticed the following error:

Event ID: 1004, Source: Application Error

Reporting queued error: faulting application XTE.exe, version 4.5.0.64631, faulting module ntdll.dll, version 5.2.3790.4937, fault address 0x0004cd12

Event ID 1004 faulting application XTE.exe

On investigation there is an additional hotfix (PSE450R07W2K3027) available on the Citrix website to address this specific issue.

References:

http://support.citrix.com/article/CTX131874

http://forums.citrix.com/thread.jspa?messageID=1611389

Prevent users from connecting to a Citrix server while performing maintenance

Here is a command for preventing users from connecting to a Citrix server while you are performing maintenance or patching. From the command prompt type:

change logon /disable

When you have finished your maintenance, simply run:

change logon /enable

Be aware that this will also stop you from connecting to the server via RDP if you end your session. Rebooting the server resets this command. This command also works for Terminal Server/Remote Desktop Services.

FRS or DFSR not replicating certain files

I had an issue today where a file that I had added to the SYSVOL share on my network, hadn’t been replicated to other domain controllers. The file was a jpeg that had been created by our designer, which needed to be pushed out to client computers using group policy preferences. I modified the GPO last week, but noticed this morning that the file wasn’t being to copied to all client computers. I had a look at the location where I had created the file in the SYSVOL share on various domain controllers, and found that the file hadn’t been replicated to any of them. In fact, it was only present on the server that I had originally copied it to.

I checked the logs on a few of the domain contollers for errors with the File Replication Service, but there were none. Next I created a test text file in the SYSVOL share to see if it replicated to other domain controllers and it replicated straight away. On further investigation I discovered that the temp attribute had been set on the jpeg file for some reason when it was created, and therefore it was being ignored for the purposes of replication by FRS, which is the standard behaviour, and also applies to DFSR.

You can’t view the temp or ‘T’ attribute using the attrib command, so a grabbed a utility called BulkFileChanger which verified this and allowed also allowed me to quickly remove the temp attribute. I then recopied the file to the SYSVOL share and it replicated to the other servers as normal.

Alternatively, you could use fsutil to discover the current attributes set on the file or files, and then use powershell to reset the attributes as outlined in the technet article below.    

References:

http://social.technet.microsoft.com/wiki/contents/articles/dfsr-does-not-replicate-temporary-files.aspx

 

Force reboot of a remote server that has hung shutting down

I had an issue last night when a remote server that I was applying windows updates to, hung while it was shutting down. I will still able to ping the server, and access its file shares, but was unable to get RDP access. I was cursing at this point, with the prospect of a long journey the following day to investigate and bring the server back online. I then considered what other steps I could take to try and force the server to reboot remotely. I used the PSTools command psexec to see if I could still get command line access to the remote server, and fortunately I could. Next I tried to force a reboot of the remote server using psexec and the shutdown command as follows, where REMOTE_SERVER_NAME is the name of the remote server that I was trying to reboot:

psexec \\REMOTE_SERVER_NAME shutdown /r /t 01

alternatively you could use:

shutdown /m \\REMOTE_SERVERNAME /r /t 01

This returned the following error:

1115 A system shutdown is in progress

This basically meant that a system shutdown was already in progress,  and therefore the command was unable to force a reboot. In the end I used the pskill command to stop the winlogon service on the remote server to try and release whichever process wass causing the server to hang on shutdown. I should stress that this was a last resort, and not something that I would recommend doing unless essential:

pskill \\REMOTE_SERVER_NAME  winlogon

Anyway, after another few minutes the remote server did finally restart, although there are a few other things that I should mention that happened in the process. The operating system on this machine was Windows Server 2008 R2. After the server came back up (verified by ping -t REMOTE_SERVER_NAME) I tried to RDP the box again. I was able to enter my credentials and the logon process appeared to start, but after a few seconds the following message appeared on the screen:

Please wait for the Windows Modules Installer

The machine sat like that for quite some time, and then started ‘Configuring Updates’. My RDP session then abruptly ended and the server restarted itself again. Again, when it was back up I tried to RDP the server again and received the ‘Please wait for the windows modules installer message’ for a second time. Thankfully, after a few minutes and another ‘configuring updates’ message, logon continued and ther server was back up and running. On checking the event log and windows update log I was able to verify that all the updates had installed OK, and there were no other errors worthy of note. So in summary, if you want to save yourself a long trip, to most likely press a power or reset switch, you may want to try the above first.