LoDoGg Forums

Funny Pictures : Screen Cleaner!

Tue, 01 Jun 2010 08:17:22 +0000

Author: lodogg
Subject: Screen Cleaner!
Posted: 01 June 2010 at 8:17am

I still love this...

Windows 2000 & 2003 Server : How can I import BIND DNS into an Active Directory

Thu, 26 Feb 2009 21:44:15 +0000

Author: lodogg
Subject: How can I import BIND DNS into an Active Directory
Posted: 26 February 2009 at 9:44pm

I found this great post!

-------------------

We are currently running BIND 9 on Windows servers for DNS. I'd like to convert this over to an AD DNS implementation since we are converting everything to Active Directory.

Is there a way I can simply import the BIND .DNS files that I have? Typing all this in is going to be tedious and troublesome...

-------------------
I'm not an expert in this area but while someone else responds.. what I would do is setup zone transfers on the BIND servers to your AD DNS Server. Then, allow on your AD DNS server non secure updates temporarily from that host. In a nutshell. The issue then will be to set your clients now to point to the new DNS Server. Also, i'm not sure how the created records in your new AD DNS will dynamically update once clients change IPs, etc.

-------------------

Well the idea is to get away from BIND completely, so they won't need to update in the future... it will all be AD. My question, I guess, is how can I allow BIND to do a zone transfer to an AD server? I don't know much abotu BIND and all I can seem to find is information about incremental zone transfers which I don't want, I want the whole kit and kaboodle moved over ASAP!

-------------------

Not necessary to allow dynamic updates to implement the above zone-transfer method, but should be enabled to simplify management of DNS when clients register themselves.
When storing zone in AD you can secure the zone-data to only allow secure updates to require that the computer is member of AD.

Method 1:
As above BIND-server nead to allow zone-transfers.
Create a new secondary zone on AD-server pointing to the BIND-server.
Zone will be transfered automatically when incrementing serial number for zone on master server Change zone-type on AD-server to be primary zone and enable that data shall be stored in AD.

Method 2:
Create a new primary zone on AD-server without enabling that data shall be stored in AD.
Copy the original dns-file from BIND-server to %WINDIR%\System32\dns on AD-server.
Reload the zone
Change the zone-property to be stored in AD. Gives better security and replication than old primary/secondary file usage.

Method 3:
Create primary zone on AD-server and allow dynamic updates for the zone.
Change the clients to use the new DNS-server (preferably done through DHCP) and run ipconfig/registerdns or wait until they do it automatically.

-------------------

OK, so I am gathering that I still need to create the zones on the Windows/AD DNS server first, then BIND will transfer them to the AD server...?

Will the static records get pushed to the AD server? I am seeing conflicting info here....?

I only need it to transfer all my static entries one time, not dynamically over time. Once they are transferred, I am going to turn BIND off and use all Active Directory for DNS.

-------------------

Zone transfer will transfer all records for the DNS-zone.

You will get a conflict when clients try to register dynamic and you have static records resulting in logging that the client could not register/update its record in DNS.

-------------------

Yeah, you have to create the zone in your AD DNS in order to receive zone transfers. Unfortunately, i don't think you'll be able to differentiate the type of records you want transfered by static/dynamic like Henjoh09 said.

What I would do about the dynamic records is to do the zone transfers anyways and then script the updating of those records that are dynamic to either, change them (still waiting on a colleagues answer on how to differentiate between a static record and a dynamic record), or delete it and have it recreated (if it can't be scripted to change a record from static to dynamic). To create the list of dynamic records I would just create a simple AD query for all computer objects. It's good that even cluster names appear as a computer object in AD. Then use that list for either the script that modifies the dynamic records, or the script that will delete the static records and have them be recreated via a psexec ipconfig /registerdns etc. Either way you would need it.

To get that list ...

1. launch the command prompt as an administrator

2. type "dsquery computer" or "dsquery computer OUpath parameters" http://technet.microsoft.com/en-us/library/cc730720.aspx

3. At the end of the previous command before pressing enter add the -limit parameter or else it will cap off at 100 entries. You can type 0 as the value after -limit so that all entries are returned.

4. At the end of that type the > for piping the results to a txt file of your choosing. Before the pipe you can add -uoc to specify Unicode as output

5. The whole thing should look like "dsquery computer -limit 0 -uoc > c:\mycomputerobjects.txt"

6. Create a cheesy script, or even better, open it using Excel but use the comma as the delimiting value to split the distinguished name up. The first field will be the canonical name CN. That should contain the name of the computer object itself. Only copy that column. Paste it into notepad. Do a "Replace.." to replace all instances of "CN=" with nothing. Vuala there is your a list of a ton of dynamic records that need changing.

-------------------

I forgot to tell you. If my colleague confirms that there is a parameter of the records themselves that can be modified to make it a dynamic record then http://msdn.microsoft.com/en-us/library/ms682132(VS.85).aspx can be used to script your modification of all the Address Records using the list created with the above 6 steps. I can help you with that.

-------------------

I can tell you it went just fine, the records in the DNS zones came right over without a hitch. I'm still testing it but so far everything looks fantastic.

Misc : 2000 Office

Fri, 06 Feb 2009 22:54:07 +0000

Author: lodogg
Subject: 2000 Office
Posted: 06 February 2009 at 10:54pm

Do you have the latest Service Pack installed?

SP3 for Office 2000
http://www.microsoft.com/downloads/details.aspx?FamilyID=5C011C70-47D0-4306-9FA4-8E92D36332FE&displaylang=EN

You need to search for the normal.dat file not normal.dot. Here is a good artical on the normal.dat file. http://support.microsoft.com/kb/214215

If you are still having issues you can try to repair the installation. Go to Start -> Control Panel -> Add/Remove Programs and highlight the Office 2000 program then choose the Change button and this will allow you to run a repair.

Funny Video's : Steves Riding Lawn Mower

Fri, 06 Feb 2009 19:24:38 +0000

Author: lodogg
Subject: Steves Riding Lawn Mower
Posted: 06 February 2009 at 7:24pm

This guy is great..

[tube]95qZtwJNjxk[/tube]

[tube]RNPxIibhcKY[/tube]

Cisco : Cisco router IOS (2610) as a VPN Server

Wed, 28 Jan 2009 00:04:00 +0000

Author: judithscott
Subject: Cisco router IOS (2610) as a VPN Server
Posted: 28 January 2009 at 12:04am

its very nice information, thank you for giving this information, i will try this.

Cisco : Sending Cisco syslogs to a server

Wed, 28 Jan 2009 00:00:24 +0000

Author: judithscott
Subject: Sending Cisco syslogs to a server
Posted: 28 January 2009 at 12:00am

Originally posted by lodogg

Syslogs

The syslogs are useful when troubleshooting issues on the PIX. Cisco offers a free syslog server for Windows NT called PIX Firewall Syslog Server (PFSS), which you can download from the Downloads. There are a number of other vendors, such Kiwi Enterprises, that offer syslog servers for various Windows platforms, including Windows 2000 and Windows XP. Most UNIX and Linux boxes have syslog servers installed by default.

When the syslog server is set up, configure the PIX to send logs to it.

Example

logging on
logging host <ip_address_of_syslog_server>
logging trap debugging

Note: The configuration above sets the PIX to send Debugging (level 7) and more critical syslogs to the syslog server. These are the most verbose logs the PIX sends out, and they should be used only when trying to troubleshoot an issue. For normal operation, it is recommended that the logging level be set to Warning (level 4) or Error (level 3).

If you are having an issue with slow performance, open the syslog in a text file and search for the source IP address that is having a problem. (Or, if you are using UNIX, grep through the syslog for the source IP address.) Check to see if you are receiving any messages indicating that the external server is trying to access the internal IP address on TCP port 113 (for Identification protocol [Ident]) but that the PIX is denying the packet. The message should be similar to the following example.

%PIX-2-106001: Inbound TCP connection denied from 
10.64.10.2/35969 to 172.17.110.179/113 flags SYN

If you are receiving this message, issue the service reset inbound command to the PIX. This will cause the PIX to immediately reset any inbound connection that is denied by the security policy, instead of silently dropping the packets. Instead of the server waiting for the Ident packet to time out its TCP connection, it will immediately receive a reset packet. for more information on the PIX and Ident, refer to PIX Performance Issues Caused by IDENT Protocol.

it's very useful information and thanks for sharing.

Cisco : Cisco Reverse Telnet -AUX - Console

Sun, 25 Jan 2009 10:40:49 +0000

Author: lodogg
Subject: Cisco Reverse Telnet -AUX - Console
Posted: 25 January 2009 at 10:40am

So after you have your loopback IP Address set you need to run the following command:

telnet (loopbback) (line port)

Example:

telnet 10.2.2.1 2005

Cisco : Cisco Reverse Telnet -AUX - Console

Sun, 25 Jan 2009 10:38:41 +0000

Author: lodogg
Subject: Cisco Reverse Telnet -AUX - Console
Posted: 25 January 2009 at 10:38am

Reverse Telnet gives you the ability to telnet to a device, and then console to another device from there. For example, you could telnet to a router, and then console into a switch, or a modem, or anything that has a console port.  There are alot of devices out there that dont have remote access built into them, their only option is a console session.  Well, this will allow you to remotely manage these devices.

Before we even begin, lets set up the cabling first.

You need a straight through cable going from the console port of the console-only device to the AUX port on your router.

Now lets get going with the router config:

In order to set up reverse telnet, these are the steps:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1.  Configure the AUX port.

router#config t
router(config)#line aux 0
router(config-line)#modem InOut
router(config-line)#transport input all
router(config-line)#speed 19200
router(config-line)#exit

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2.  Then you must create a loopback addresss

router#config t
router(config)#int loopback 0
router(config-if)#ip address 10.0.0.1 255.0.0.0
router(config-if)#no shut
router(config-if)#exit

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.  Now you must find out what "line" the router uses for the AUX port.

OUTSIDE OF CONFIG MODE (hit CTRL-Z to get out) enter the command "sh line"
you will get an output resembling the following:

router#sh line
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
     0 CTY              -    -      -    -    -      0       0     0/0       -
   225 AUX  19200/19200 - inout     -    -    -      0       0     0/0       -
*  226 VTY              -    -      -    -    -     10       0     0/0       -
   227 VTY              -    -      -    -    -      0       0     0/0       -
   228 VTY              -    -      -    -    -      0       0     0/0       -
   229 VTY              -    -      -    -    -      0       0     0/0       -
   230 VTY              -    -      -    -    -      0       0     0/0       -

This particular router (a 3660) uses line 225 for the AUX port.

--------

This is the output from a 2611.

router#sh line
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
     0 CTY              -    -      -    -    -      0       0     0/0       -
    65 AUX  19200/19200 - inout     -    -    -      8       0  2177/0       -
*   66 VTY              -    -      -    -    -     24       0     0/0       -
    67 VTY              -    -      -    -    -      3       0     0/0       -
    68 VTY              -    -      -    -    -      1       0     0/0       -
    69 VTY              -    -      -    -    -      0       0     0/0       -
    70 VTY              -    -      -    -    -      0       0     0/0       -

It uses line 65 for the AUX port. (The port with the * by it is
the line you are currently connected to.)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4.  Telnet:

To do this, you will telnet to the IP address you set on the loopback interface.
The port number you will telnet to is 2000+line#.

So for the 3660, assuming my loopback interface has IP address of 10.0.0.1,
I would telnet to 10.0.0.1:2225

For the 2611, assuming my loopback interface has IP address of 10.0.0.1,
I would telnet to 10.0.0.1:2065.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5. Finishing:

When you are done, while holding the keys CTRL+SHIFT+6, press the letter X.
This will kick you out of the AUX port.

The router will still keep the line connected and no one will be able to
retelnet back in until you clear the line.

To do this, OUTSIDE OF CONFIG MODE (hit CTRL-Z to get out of config mode)
you enter the command "clear line xxx" where "x" is the line#.

So for the 3660, I would enter "clear line 225"

On the 2611, I would enter "clear line 65"

It will ask you to confirm, just hit the enter key.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And that is everything there is to know about reverse telnetting.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here is a sample configuration, this is everything you need to reverse telnet:

sample-config#sh run
Building configuration...

Current configuration : 3481 bytes
!
!
interface Loopback0
ip address 10.0.0.1 255.0.0.0
!
line con 0
transport input none
line aux 0
modem InOut
transport input all
speed 19200
line vty 0 4
password xxxxxxx
login
!
end

Cisco : Cisco VPN Client to PIX with AES

Mon, 12 Jan 2009 22:48:52 +0000

Author: lodogg
Subject: Cisco VPN Client to PIX with AES
Posted: 12 January 2009 at 10:48pm

This was a great document I found.

Introduction¶

This guide provides information that can be used to configure a Cisco PIX/ASA device running firmware version 7.x to support IPsec VPN client connectivity. If you have a PIX device running firmware version 6.x, please consult the HowtoCiscoPix. The Shrew Soft VPN Client has been tested with Cisco products to ensure interoperability.

Overview¶

The configuration example described below will allow an IPsec VPN client to communicate with a single remote private network. The client uses the pull configuration method to acquire the following parameters automatically from the gateway.

IP Address
IP Netmask
DNS Servers
DNS Default Domain Suffix
DNS Split Network Domain List
WINS Servers
PFS Group
Remote Network Topology
Login Banner

Gateway Configuration¶

This example assumes you have knowledge of the Cisco ASA gateway command line configuration interface. For more information, please consult your Cisco product documentation.

Interfaces¶

Two network interfaces are configured. The outside interface has a static public IP address of 1.1.1.20 which faces the internet. The inside interface has a static private IP address that faces the internal private network. The default gateway is configured as 1.1.1.3 via the outside interface.

interface Vlan1 nameif inside security-level 100 ip address 10.1.2.20 255.255.255.0!interface Vlan2 nameif outside security-level 0 ip address 10.1.1.20 255.255.255.0!interface Ethernet0/0 switchport access vlan 2!

Access List¶

An access lists must be configured to define the IPSec policies. This is expressed with the source matching the local private network(s) and the destination matching any as the VPN client address will be assigned by the gateway.

object-group network group-inside-vpnclient description All inside accessible networks network-object 10.1.2.0 255.255.255.0access-list acl-vpnclient extended permit ip object-group group-inside-vpnclient any

Address Pool¶

The IP address pool must be configured. Clients will be assigned private network addresses from a pool of 10.2.20.1-10.2.20.126.

ip local pool ippool-vpnclient 10.2.20.1-10.2.20.126 mask 255.255.255.0

User Authentication¶

User authentication must be configured to support IKE extended authentication ( XAuth ). In this example, we use define user accounts locally on the ASA. It is possible to pass this authentication to a radius or an LDAP account server using the Cisco AAA authentication mechanism. For more information, please consult your cisco product documentation.

aaa authentication ssh console LOCALusername bill password XXX encryptedusername bob password XXX encrypted

IPsec Parameters¶

A transform set and dynamic IPsec crypto map must be configured to support client VPN connections. The dynamic crypto map is then assigned to a standard crypto map and bound to the outside ( public ) interface.

crypto ipsec transform-set xform-3des-md5 esp-3des esp-md5-hmaccrypto dynamic-map dcmap-vpnclient 1 set transform-set xform-3des-md5crypto map cmap-vpncient 65535 ipsec-isakmp dynamic dcmap-vpnclientcrypto map cmap-vpncient interface outside

ISAKMP Parameters¶

The ISAKMP protocol must be enabled on the outside ( public ) interface and an ISAKMP policy must be configured. NAT Traversal is also enabled to allow clients to communicate effectively when their peer address is being translated. The keep alive packet rate is set to 20 seconds.

crypto isakmp enable outsidecrypto isakmp identity addresscrypto isakmp nat-traversal 20crypto isakmp policy 1 authentication pre-share encryption 3des hash md5 group 2 lifetime 86400

Group Policy¶

A group policy must be configured to provide the client with dynamic configuration information.

group-policy group-policy-default internalgroup-policy group-policy-default attributes banner value Welcome to the shrew.net ciscoasa wins-server value 10.1.2.100 10.1.2.1 dns-server value 10.1.2.100 10.1.2.1 vpn-tunnel-protocol IPSec password-storage disable re-xauth disable pfs disable split-tunnel-policy tunnelspecified split-tunnel-network-list value acl-vpnclient default-domain value shrew.net split-dns value shrew.net example.com

Tunnel Group¶

A tunnel group must be configured to define the VPN Client tunnel parameters. It is created using the type ipsec-ra for IPsec remote access. The client uses the tunnel group name as its FQDN identity value and the tunnel group pre-shared-key as its pre-shared key value.

tunnel-group vpnclient type ipsec-ratunnel-group vpnclient general-attributes address-pool ippool-vpnclient default-group-policy group-policy-defaulttunnel-group vpnclient ipsec-attributes pre-shared-key mypresharedkey

Client Configuration¶

The client configuration in this example is straight forward. Open the Access Manager application and create a new site configuration. Configure the settings listed below in the following tabs.

General Tab¶

The Remote Host section must be configured. The Host Name or IP Address is defined as 10.1.1.20 to match the ASA outside ( public ) interface address. The Auto Configuration mode should be set to ike config pull.

Phase 1 Tab¶

The Proposal section must be configured. The Exchange Type is set to aggressive and the DH Exchange is set to group 2 to match the ASA ISAKMP policy definition.

Authentication Tab¶

The client authentication settings must be configured. The Authentication Method is defined as Mutual PSK + XAuth.

Local Identity Tab¶

The Local Identity parameters are defined as Fully Qualified Domain Name with a FQDN String of "vpnclient" to match the ASA tunnel group name.

Remote Identity Tab¶

The Remote Identity parameters are set to IP Address with the Use a discovered remote host address option checked to match the ASA ISAKMP identity parameter.

Credentials Tab¶

The Credentials Pre Shared Key is defined as "mypresharedkey" to match the ASA tunnel group pre-shared-key.

Known Issues¶

Cisco gateways support a proprietary form of hybrid authentication which does not conform to RFC draft standards. At this time the Shrew Soft VPN Client does not support this authentication mode. We hope to add support for this in the future.

Resources¶

Cisco : Cisco VPN Client to PIX with AES

Mon, 12 Jan 2009 22:45:19 +0000

Author: lodogg
Subject: Cisco VPN Client to PIX with AES
Posted: 12 January 2009 at 10:45pm

uploads/1/vpnrmote.pdf

Here is another document on terminating a VPN connection on an ASA / PIX.