ASA VPN LDAP authentication notes

1. beware use the group that is the user directly belongs to, avoid the recursive list of nested predecessors.
it might won't work if break this rule

2. beware the NAT rule, you need a rule for the VPN

active directory (User Security Attributes)

memberOf

The memberOf attribute is a multi-valued attribute that contains groups of which the user is a direct member, except for the primary group, which is represented by the primaryGroupId. Group membership is dependent on the domain controller (DC) from which this attribute is retrieved:

• At a DC for the domain that contains the user, memberOf for the user is complete with respect to membership for groups in that domain; however,memberOf does not contain the user's membership in domain local and global groups in other domains.
• At a GC server, memberOf for the user is complete with respect to all universal group memberships.

If both conditions are true for the DC, both sets of data are contained in memberOf.

Be aware that this attribute lists the groups that contain the user in their member attribute—it does not contain the recursive list of nested predecessors. For example, if user O is a member of group C and group B and group B were nested in group A, the memberOf attribute of user O would list group C and group B, but not group A.

This attribute is not stored—it is a computed back-link attribute.

Using Lync 2010 client in Office Communications Server 2007 R2 environment

While the new Lync Client brings a lot of new functionalities and a complete new look, it isn’t compatible with a OCS 2007 R2 environment. Another downside is that it can’t be installed together with Communicator 2007 on a single machine. When working on both 2007 R2 and Lync 2010 projects, this means the usage of VM’s or uninstall and re-installing a lot, two options which I don’t like personally.

Out-of-the-box the client will give you an error message when you try to sign in into an OCS 2007 R2 pool, stating that the version is not correct. This tells me there IS some kind of communication, however, it’s being detected and blocked.

After some research I found a way to be able to run the Lync 2010 client on a OCS 2007 R2 environment – simply by bypassing a version check. To bypass this check, you have to create a new registry entry:

Key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator
Name:  DisableServerCheck
Type: DWORD
Value: 1 (00000001)

When this entry has been created, the version check will be skipped, and the Lync Client WILL logon to the OCS 2007 R2 environment. Actually, most of the functionalities just work fine! IM, Presence, calling and video work all as espected.

Of course there are some functionalities which don’t work correctly. One of these functionalities is the “Live Meeting” functionality; this is now built-in into the Lync Client, while in the previous version it was a separate client. Installing Lync will uninstall the LiveMeeting plug-ins in outlook as well, disabling you to schedule an old-fashion meeting. But hey, at least now we can connect to both environments with this new client!

non-DID number calling in Lync or OCS

For the Location Profile you have to make an additional regular expression rule that expands non-DID extensions to the format as presented above:

Pattern: ^(50\d{3})$
Translation: +49690000;ext=$1


Note. When you use this format, no other phone number in your Lync deployment can be assigned the number, +12125550100, without an extension. You must configure the auto attendant with an extension (for example tel:+12125551000;ext=0), and create a normalization rule to normalize incoming call for +12125550100 to tel:+12125551000;ext=0. This can be accomplished by creating a pool level dial plan for the gateway receiving the inbound call.

Migrating from OCS 2007 R2 to Lync

There are 4 parts to the article.

http://www.simple-talk.com/sysadmin/unified-messaging/migrating-from-ocs-2007-r2-to-lync-part-i/

http://www.simple-talk.com/sysadmin/unified-messaging/migrating-from-ocs-2007-r2-to-lync-part-2/

http://www.simple-talk.com/sysadmin/unified-messaging/migrating-from-ocs-2007-r2-to-lync---part-3/

http://www.simple-talk.com/sysadmin/unified-messaging/migrating-from-ocs-2007-r2-to-lync-part-4/

Understanding Partitions and Calling Search Spaces

Understanding Partitions and Calling Search Spaces

A partition comprises a logical grouping of directory numbers (DNs) and route patterns with similar reachability characteristics. Devices that are typically placed in partitions include DNs and route patterns. These entities associate with DNs that users dial. For simplicity, partition names usually reflect their characteristics, such as "NYLongDistancePT," "NY911PT," and so on.

A calling search space comprises an ordered list of partitions that users can look at before users are allowed to place a call. Calling search spaces determine the partitions that calling devices, including IP phones, softphones, and gateways, can search when attempting to complete a call.

When a calling search space is assigned to a device, the list of partitions in the calling search space comprises only the partitions that the device is allowed to reach. All other DNs that are in partitions that are not in the device calling search space receive a busy signal.

Partitions and calling search spaces address three specific problems:

Routing by geographical location
Routing by tenant
Routing by class of user

Partitions and calling search spaces provide a way to segregate the global dialable address space. The global dialable address space comprises the complete set of dialing patterns to which Cisco Unified Communications Manager can respond.

Partitions do not significantly impact the performance of digit analysis, but every partition that is specified in a calling device search space does require that an additional analysis pass through the analysis data structures. The digit analysis process looks through every partition in a calling search space for the best match. The order of the partitions that are listed in the calling search space serves only to break ties when equally good matches occur in two different partitions. If no partition is specified for a pattern, the pattern goes in the null partition to resolve dialed digits. Digit analysis always looks through the null partition last.

You can associate partitions with a time schedule and a time zone. Associating a partition to a time schedule and a time zone allows configuration of time-of-day routing for calls that are coming into a partition and the associated calling search spaces of the partition. See "Time-of-Day Routing" for more information.

If you configure a calling search space both on an IP phone line and on the device (IP phone) itself, Cisco Unified Communications Manager concatenates the two calling search spaces and places the line calling search space in front of the device calling search space. If the same route pattern appears in two partitions, one contained in the line calling search space and one contained in the device calling search space, Cisco Unified Communications Manager selects the route pattern that is listed first in the concatenated list of partitions (in this case, the route pattern that is associated with the line calling search space).

Note : Cisco recommends avoiding the configuration of equally matching patterns in partitions that are part of the same calling search space or part of different calling search spaces that are configured on the same phone. This practice avoids the difficulties that are related to predicting dial plan routing when the calling search space partition order is used as a tie breaker.

Before you configure any partitions or calling search spaces, all directory numbers (DN) reside in a special partition named <None>, and all devices are assigned a calling search space also named <None>. When you create custom partitions and calling search spaces, any calling search space that you create also contains the <None> partition, while the <None> calling search space contains only the <None> partition.

Note : Any device that is making a call can explicitly reach any dial plan entry that is left in the <None> partition. To avoid unexpected results, Cisco recommends that you do not leave dial plan entries in the <None> partition.

See the "Local Route Groups" chapter in the Cisco Unified Communications Manager Features and Services Guide for an explanation of local route groups and the details of provisioning route groups, device pools, route lists, partitions, route patterns, and calling search spaces in a local route group scenario.

DHCP ip helper-address

 Much of the time though, we don't have a DHCP server that "touches" every LAN in our network. Sometimes the DHCP servers will actually be in a completely different location. So more magic comes into play here.

There are DHCP forwarding agents that can be involved. This piece of code will see the 255.255.255.255 UDP broadcast to the DHCP port and forward it on as a unicast packet (through the network) to a pre- determined address. Routers have this function called an "ip helper-address."

So let's put our DHCP server on a 192.168.66.254 address, which is in some other location physically. When a workstation on VLAN1 powers up, it doesn't know what its IP is, so it sends out the DHCP Discover packet to 255.255.255.255. The forwarding agent (router) receives this broadcast and activates the helper-address code. This resends the message as a unicast packet to 192.168.66.254. So the DHCP server receives it.

The next catchy part here is to work backwards to figure out what's going on. The DHCP server receives the packet now, which is one step, but the next part is to try to determine which scope the IP needs to be assigned from. Remember, the workstation that was booting doesn't know who it is, and only has its MAC address already assigned. So unless you have a reservation by MAC address set up, this won't help much in narrowing things down.

There are two options though. First, when the router or forwarding agent resends the DHCP Discover packet as a unicast, it not only rewrites the destination address to 192.168.66.254, but also rewrites the source address to its own received interface (192.168.1.253). The DHCP server can match the pool of the IP source.

Another option is that the DHCP forwarding agent (a.k.a. relay agent) can also insert a field within the DHCP information called a "giaddr" field, or "Gateway Interface Address" which allows the DHCP process to figure out what the original receiving interface was in order to select a pool of addresses.

free ssl certification for 90days

comodo

http://www.instantssl.com/ssl-certificate-products/free-ssl-certificate.html

Junos OSPF

OSPF Designated Router

OSPF elects a Designated Router (DR) for each broadcast network to act as the main point of contact for the network segment. Each router on the segment becomes adjacent with the DR, which handles all LSAs for the network. Each router sends the DR information using the multicast address 224.0.0.6. The DR sends the network LSA (LSA Type 2) to represent the broadcast network to the rest of the OSPF area. 

To avoid DR as a single point of failure, a Backup Designated Router (BDR) is also elected for the broadcast network. The BDR also listens to 224.0.0.6 multicast address and becomes active in case of DR failure. Like DR, all the routers on the broadcast network also form FULL adjacency with the BDR. 
for priority: set protocol ospf area 0.0.0.0 interface eth0.0 priority 255

Network topology:

OSPF Configuration:

SRX210 OSPF Configuration

interface {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 172.16.6.20/24;
            }
        }
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface  ge-0/0/0.0;
        }
    }
}

J4350 OSPF Configuration

interface {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 172.16.6.10/24;
            }
        }
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface ge-0/0/0.0;
        }
    }
}

J2350 OSPF Configuration

interface {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 172.16.6.15/24;
            }
        }
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface ge-0/0/0.0;
        }
    }
}

OSPF DR Election:
On a broadcast network, DR election takes place based on OSPF router priority. The Priority is set to 128 by default by JUNOS software. In case of a tie, the router with highest router-id is elected the DR.

OSPF Priority is exchanged by OSPF Hello packets. A router with priority 0 is ineligible to become a DR or BDR. Once a DR is elected, a BDR is elected in the similar fashion. 

All routers on the broadcast segment form FULL adjacency with, both, DR and BDR. All other routers on the segment are in DROTHER state.

In this case, since all router report the same OSPF priority, the router IDs are used to elect DR and BDR. Since the SRX210 router has the highest IP address, it becomes the DR with J2350 as BDR.

OSPF Adjacency and Neighbors

SRX210 router:

root> show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/0.0          DR      0.0.0.0         172.16.6.20     172.16.6.15        2

root> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.16.6.15      ge-0/0/0.0             Full      172.16.6.15      128    31
172.16.6.10      ge-0/0/0.0             Full      172.16.6.10      128    33

J4350 router:

root> show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/0.0          DRother 0.0.0.0         172.16.6.20     172.16.6.15        2

root> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.16.6.20      ge-0/0/0.0             Full      172.16.6.20      128    36
172.16.6.15      ge-0/0/0.0             Full      172.16.6.15      128    34

J2350 router:

root> show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/0.0          BDR     0.0.0.0         172.16.6.20     172.16.6.15        2

root> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.16.6.20      ge-0/0/0.0             Full      172.16.6.20      128    37
172.16.6.10      ge-0/0/0.0             Full      172.16.6.10      128    32

Only DR sends network LSAs (LSA Type 2) to all other routers on the broadcast segment. This network LSA contains information about all routers attached to this broadcast segment. Here, the SRX210 router (router ID: 172.16.6.20) is advertising Type 2 LSAs.

LSA Type 2

SRX210 router:

root> show ospf database network extensive

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Network *172.16.6.20      172.16.6.20      0x80000009    79  0x22 0x9179  36
  mask 255.255.255.0
  attached router 172.16.6.20
  attached router 172.16.6.15
  attached router 172.16.6.10
  Gen timer 00:48:41
  Aging timer 00:58:41
  Installed 00:01:19 ago, expires in 00:58:41, sent 00:01:18 ago
  Last changed 00:01:19 ago, Change count: 9, Ours

J4350 router:

root> show ospf database network extensive

    OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Network  172.16.6.20      172.16.6.20      0x80000009   846  0x22 0x9179  36
  mask 255.255.255.0
  attached router 172.16.6.20
  attached router 172.16.6.15
  attached router 172.16.6.10
  Aging timer 00:45:53
  Installed 00:14:04 ago, expires in 00:45:54, sent 00:22:06 ago
  Last changed 00:14:04 ago, Change count: 8

J2350 router:

root> show ospf database network extensive

    OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Network  172.16.6.20      172.16.6.20      0x80000009   950  0x22 0x9179  36
  mask 255.255.255.0
  attached router 172.16.6.20
  attached router 172.16.6.15
  attached router 172.16.6.10
  Aging timer 00:44:10
  Installed 00:15:48 ago, expires in 00:44:10
  Last changed 00:15:48 ago, Change count: 8

create file in Cisco router flash

Router#tclsh
Router(tcl)#puts [open "flash:test" w+] {
+>This is a test.
+>Line 2.
+>Third line.
+>}

Router(tcl)#tclquit

Router#more flash:test
This is a test.
Line 2.
Third line.

vtp md5 mismatch errors

some time, all the vtp domain and pass is match , but you still get error message like
*** MD5 digest checksum mismatch on trunk:

solution: on server switch, create a vlan, could fix the problem
or you can try change server to client mode then back to server.