Flomain Networking https://www.flomain.de Everything Networking Wed, 12 Sep 2018 11:30:27 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.8 https://www.flomain.de/wp-content/uploads/2016/11/favicon-image.png Flomain Networking https://www.flomain.de 32 32 20143597 IAP VPN Guest Solution With Captive Portal https://www.flomain.de/2018/09/iap-vpn-guest-solution-with-centralised-portal/ https://www.flomain.de/2018/09/iap-vpn-guest-solution-with-centralised-portal/#respond Wed, 12 Sep 2018 11:30:27 +0000 https://www.flomain.de/?p=1131 After my last post about an IAP VPN, I’ve got a lot of questions regarding an IAP VPN guest solution, either with or without a captive portal. This post is all about an IAP VPN guest solution. I use a controller as the VPN concentrator and for the captive portal. You can use ClearPass for the […]

The post IAP VPN Guest Solution With Captive Portal appeared first on Flomain Networking.

]]>
After my last post about an IAP VPN, I’ve got a lot of questions regarding an IAP VPN guest solution, either with or without a captive portal. This post is all about an IAP VPN guest solution. I use a controller as the VPN concentrator and for the captive portal. You can use ClearPass for the captive portal as well.

This kind of solution is very handy if you need to provide a centralized guest access, e.g. with a controller in the DMZ. If you just need a tunnel for your clients back to a central site, follow this post instead:

Aruba Instant VPN with Central – IAP VPN

IAP VPN Guest: Controller Part

You need an Aruba controller. This controller needs to be reachable by all IAP’s using GRE. For the basic configuration, this controller does not need any licenses. But if you like to be more flexible, you need at least one AP and PEF license. This is just to enable the firewall and role features.

I also assume that the controller is able to transfer the guest traffic to the destination. In my setup, I use an L2 VLAN on the controller. So you need a firewall or at least a router who send the guests to the internet. You also need an external DHCP server. From my point of view, this makes the most sense, as the controller acts only as the VPN concentrator and provides the captive portal.

The first step is to build the GRE tunnel on the controller. Go to “Configuration–>Interfaces–>GRE Tunnels” and create a new GRE tunnel:

IAP VPN Guest - Create a GRE Tunnel on the Controller

IAP VPN Guest – Create a GRE Tunnel on the Controller

Choose a “Tunnel ID” and select “1” as the “Protocol”. Put in all the VLAN’s you need and make sure you check the “Enable” checkmark. Leave the “Trusted” checkmark unchecked. Select an IP for the “Tunnel source” and configure the “Tunnel destination”. This is the IP of the IAP. Make also sure, that the “Enable keepalive” switch is off:

IAP VPN Guest - Create a GRE Tunnel on the Controller Keepalive

IAP VPN Guest – Create a GRE Tunnel on the Controller Keepalive

If this is enabled, the tunnel will not come up.

It looks like this in the running config:

interface tunnel 1
    tunnel mode gre 1
    tunnel source 10.201.201.11
    tunnel destination 10.202.202.10
    tunnel vlan 205

The next step is to create a role with a captive portal configuration. I simply reuse the “guest-logon” role:

user-role guest-logon
    captive-portal "default"
    access-list session ra-guard
    access-list session logon-control
    access-list session captiveportal
    access-list session v6-logon-control
    access-list session captiveportal6

Here you can customize whatever you need to make this applicable to your environment. I will create a post later on, on how to create captive portal configurations on different platforms.

I use this role in an authentication profile for VLAN 205. VLAN 205 is in my case the guest VLAN.

aaa profile "CP_IAP_VPN"
    initial-role "guest-logon"

I was here lazy as well. This is just a copy of the default profile. I only changed the “initial-role” to the “guest-logon” role.

The next step is to apply this profile to the VLAN with the guests. In my case, it is VLAN 205. Go to “Configuration–>Interfaces–>VLANs” select an exsiting or create a new VLAN and add unter “More–>Wired LAN” the profile:

IAP VPN Guest - Add Profile to VLAN

IAP VPN Guest – Add Profile to VLAN

Or from the CLI:

vlan 205 wired aaa-profile "CP_IAP_VPN"

The VLAN has no other configuration and is a pure L2 VLAN, from the controller point of view. I assume, that the VLAN is mapped to a port on the controller.

To make a captive portal in this kind of scenario possible you need to allow three-way sessions. This is needed, as the controller is not the default gateway for the clients. Just head over to “Configuration–>Services–>Firewall” and search for the checkmark for “Allow tri-session with DNAT”:

IAP VPN Guest - Allow-Tri-Session

IAP VPN Guest – Allow-Tri-Session

It looks like this in the CLI:

firewall
    prohibit-ip-spoofing
    allow-tri-session
    attack-rate grat-arp 50 drop
    session-idle-timeout  16
    cp-bandwidth-contract untrusted-ucast 9765
    cp-bandwidth-contract untrusted-mcast 1953
    cp-bandwidth-contract trusted-ucast 65535
    cp-bandwidth-contract trusted-mcast 1953
    cp-bandwidth-contract route 976
    cp-bandwidth-contract sessmirr 976
    cp-bandwidth-contract vrrp 512
    cp-bandwidth-contract arp-traffic 976
    cp-bandwidth-contract l2-other 976
    cp-bandwidth-contract auth 976
    cp-bandwidth-contract ike 1953

With that, the controller is ready to handle the guests. Let’s configure the IAP and let the guests come.

IAP VPN Guest: The IAP Part

The IAP part is easy as well. The IAP just need IP connectivity to the controller. And NAT is not allowed between the IAP and the controller, as we use GRE for the tunnel.

To build the tunnel on the IAP go to “More–>VPN” and configure the tunnel:

IAP VPN Guest - Configure GRE on the IAP

IAP VPN Guest – Configure GRE on the IAP

From the “Protocol” drop down list select “Manual GRE” and enter the IP of the “Host”. The “GRE type” has to match the one on the controller. The “Per-AP tunnel” option can be enabled. This depends on your environment. If you just want one tunnel per IAP Cluster and if you can configure the VLAN for the guests between the IAP on the switches as a tagged VLAN you can disable this option. If the option is enabled, you need to create one tunnel per AP on the controller as well. Which could make it very complex.

Click “Next” to get to the “Enterprise Domains” page. As all the traffic is tunneled, you do not need to change anything here. This is important for split tunnel scenarios.

The next step is to create a DHCP scope for the VLAN. I knew this sounds strange, as I wrote above that we use the DHCP server in the DMZ, but before you judge me, wait for a second and read further.

To create a DHCP scope go to “More–>DHCP Server” and create a new “Centralized DHCP Scope”:

IAP VPN Guest - Add Centralized DHCP Scope

IAP VPN Guest – Add Centralized DHCP Scope

The options are very easy, just give the scope a “Name” and select “Centralized, L2” as the “Type”. This tells the IAP, that there is a DHCP server behind the tunnel and all DHCP requests are sent through the tunnel. You need to define the “VLAN” as well. Click “OK” to save the new scope.

The last step to get this working is to create a new SSID which use the scope from above. In this scenario, I use a very simple SSID configuration. To create a new SSID click “New” in the “Network” section of the IAP dashboard:

IAP VPN Guest - WLAN Settings

IAP VPN Guest – WLAN Settings

Configure the “Name” and select “Employee” for the “Primary Usage”. This sounds strange, but as we restrict access together with the captive portal on the controller, a simple “Employee” type of SSID is enough. Click “Next”:

IAP VPN Guest - VLAN

IAP VPN Guest – VLAN

The VLAN page is the important one. If you select “Virtual Controller managed” you can now select the created DHCP scope from above under “Custom”. This tells the IAP to send the traffic for this SSID through the tunnel. Click “Next”:

IAP VPN Guest - Security

IAP VPN Guest – Security

For most guest networks, the SSID is open. So is mine. If you need different security settings, you can configure them here. But remember, any kind of authentication is done at the controller. The only setting, which might make sense is a PSK to protect the SSID from unknown guests if needed. Click “Next”.

The last page is “Access”. Leave everything default, as access is restricted at the controller. Click “Finish” to save the new SSID. And thats it.

Let’s see how it looks like.

The client connects to the SSID in the IAP in the branch:

# show clients

Client List
-----------
Name             IP Address     MAC Address        OS    ESSID         Access Point       Channel  Type  Role          IPv6 Address  Signal    Speed (mbps)  
----             ----------     -----------        --    -----         ------------       -------  ----  ----          ------------  ------    ------------  
FlorianBPArbeit  10.205.205.11  78:4f:43:9d:ce:fc  OS X  Guest_Access  94:b4:0f:cb:75:cc  52E      AC    Guest_Access  --            39(good)  866(good)

On the controller it looks like this:

#show user-table 

Users
-----
    IP              MAC            Name     Role         Age(d:h:m)  Auth  VPN link  AP name   Roaming  Essid/Bssid/Phy  Profile     Forward mode  Type  Host Name  User Type
----------     ------------       ------    ----         ----------  ----  --------  -------   -------  ---------------  -------     ------------  ----  ---------  ---------
10.205.205.11  78:4f:43:9d:ce:fc            guest-logon  00:00:00                    tunnel 9  Wired                     CP_IAP_VPN  tunnel        OS X             WIRED

Here is the important part. The user has the “guest-logon” role, which we configured above on the controller. This role redirects the user to the local captive portal. So on my MacBook, it looks like this:

IAP VPN Guest - Captive Portal

IAP VPN Guest – Captive Portal

After the user enters the credentials, the role is changed. But only on the controller. On the IAP is no change at all.

#show user-table 

Users
-----
    IP              MAC            Name     Role      Age(d:h:m)  Auth  VPN link  AP name   Roaming  Essid/Bssid/Phy  Profile     Forward mode  Type  Host Name  User Type
----------     ------------       ------    ----      ----------  ----  --------  -------   -------  ---------------  -------     ------------  ----  ---------  ---------
10.205.205.11  78:4f:43:9d:ce:fc  florian   guest     00:00:03    Web             tunnel 9  Wired                     CP_IAP_VPN  tunnel        OS X             WIRED

The user has no full access or at least access in the boundaries of the applied role.

You can extend this and use ClearPass for the captive portal as well. And then you can decide whether to redirect on the controller or on the IAP. If you redirect on the IAP, you can use the automatic Aruba IPSec VPN again, from my previous post, mentioned at the beginning of this post.

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post IAP VPN Guest Solution With Captive Portal appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/09/iap-vpn-guest-solution-with-centralised-portal/feed/ 0 1131
Using Linux with OpenLDAP for User, DHCP and DNS https://www.flomain.de/2018/09/using-linux-with-openldap-for-user-dhcp-and-dns/ https://www.flomain.de/2018/09/using-linux-with-openldap-for-user-dhcp-and-dns/#respond Wed, 05 Sep 2018 11:30:01 +0000 https://www.flomain.de/?p=1094 I’m using Microsoft Active Directory in my Lab for most of the tasks, like user authentication, DNS services, and DHCP. The windows VM is getting bigger and bigger so I decided to switch to Linux. The goal is, to have my user directory, my DNS zones and DHCP subnets managed in OpenLDAP. This post shows the […]

The post Using Linux with OpenLDAP for User, DHCP and DNS appeared first on Flomain Networking.

]]>
I’m using Microsoft Active Directory in my Lab for most of the tasks, like user authentication, DNS services, and DHCP. The windows VM is getting bigger and bigger so I decided to switch to Linux. The goal is, to have my user directory, my DNS zones and DHCP subnets managed in OpenLDAP. This post shows the steps to reach this goal and how to switch from Active Directory to OpenLDAP.

First of all. I’m not an OpenLDAP expert, so everything covered in this post is working for my lab. It is not tuned or optimized.

I use the latest Debian version for my Lab server. For other distributions, the steps might differ. But the concept is still the same.

Install OpenLDAP and Configure the Basics

I assume, that the base OS is installed. I use the latest version as of today:

root@devil:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

To install OpenLDAP I followed the Debian wiki here:

https://wiki.debian.org/LDAP/OpenLDAPSetup

So the first step is to install OpenLDAP on the system:

# apt install slapd ldap-utils ldapscripts

During the installation, the system asks you for the “Administrator Password”. This is the root password for LDAP. So keep it safe and secure.

To create an initial configuration for OpenLDAP use this command:

dpkg-reconfigure -plow slapd

Answer the first question with no:

Omit OpenLDAP server configuration?

Next, the system will grab your DNS name to build the base dn. If the DNS name is not correct, replace the string with the correct DNS name.

You will now be asked for the organization name. It might be the same as the DNS name, but without the .tld part.

You need to enter a new admin password.

Choose MDB as the backend.

As this is a new install, I let the setup remove the database. so the answer is yes, to this question:

Do you want the database to be removed when slapd is purged?

Answer the next question with yes again:

Move old database?

Afterward, the setup creates all the needed files and configurations and you are done. OpenLDAP is installed.

As adviced in the Debian Wiki, I also added the additional indexes to OpenLDAP. Just create a file “indexes.ldif” with the following content:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcDbIndex
olcDbIndex: cn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: sn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: uid pres,sub,eq
-
add: olcDbIndex
olcDbIndex: displayName pres,sub,eq
-
add: olcDbIndex
olcDbIndex: default sub
-
add: olcDbIndex
olcDbIndex: uidNumber eq
-
add: olcDbIndex
olcDbIndex: gidNumber eq
-
add: olcDbIndex
olcDbIndex: mail,givenName eq,subinitial
-
add: olcDbIndex
olcDbIndex: dc eq

Make sure, that the database type matches the one you choose during initial setup.

Afterward, you can apply the indexes to OpenLDAP with this command:

# ldapmodify -Y EXTERNAL -H ldapi:/// -f indexes.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}mdb,cn=config"

To check, if the new indexes are applied, use this command:

# ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config"  -W olcDatabase={1}mdb olcDbIndex
Enter LDAP Password: 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope subtree
# filter: olcDatabase={1}mdb
# requesting: olcDbIndex 
#

# {1}mdb, config
dn: olcDatabase={1}mdb,cn=config
olcDbIndex: cn pres,sub,eq
olcDbIndex: sn pres,sub,eq
olcDbIndex: uid pres,sub,eq
olcDbIndex: displayName pres,sub,eq
olcDbIndex: default sub
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: mail,givenName eq,subinitial
olcDbIndex: dc eq

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

The system will ask for a password, but as you are on the localhost, you do not need a password.

You can now start to deploy users and groups.

There are plenty of documents on the web, who shows how to structure an LDAP directory. So I will not cover this here, but here are some good links:

My structure is as follows, but remember, this is for a lab environment (and for my home use):

OpenLDAP - My Strucuture

OpenLDAP – My Structure

On the second level, I have inserted another layer to separate my users and groups from the services like DHCP and DNS.

The first part was the easy one, lets start to integrate DHCP and DNS. It took me several weeks to figure this out.

OpenLDAP: Integrate Bind

My main goal is not performance but easy change. So I wanted to have one database for all and searched for a way to integrate Bind (my DNS server) into my OpenLDAP server. The following part shows how I did it. Bind9 can use OpenLDAP to store data for DNS zones. Other configurations like forwarders are still in the Bind config file.

First of all, you need to install the OpenLDAP extension for Bind:

# apt-get install bind9-dyndb-ldap

If you have Bind already installed, this only adds the extension. If you haven’t, this will also install Bind.

After that, you need to add the Bind schema to your OpenLDAP server. The package includes a schema file here:

/usr/share/doc/bind9-dyndb-ldap/schema.ldif.gz

But this schema file was not working for me, so I changed the schema file to this one:

# cat bind9.schema.ldif 
# This schema contains OIDs from Uninett and FreeIPA.
#
# Unninet: http://drift.uninett.no/nett/ip-nett/dnsattributes.schema
#          Base OID for DNS records is 1.3.6.1.4.1.2428.20.1,
#          see http://drift.uninett.no/nett/ip-nett/oids.html
#
# FreeIPA: http://freeipa.org/
#          Base OID for DNS records is 2.16.840.1.113730.3.8.5
#          Base OID for DNS objectClasses is 2.16.840.1.113730.3.8.6
#
# If you want to add some record types that are defined by IANA,
# please define it similar to what is done for the existing ones. The
# name should be {TYPE}Record, and OID should be
# 1.3.6.1.4.1.2428.20.1.value. For instance the RR type LOC has value
# 29, so attribute name should be LocRecord (casing shouldn't matter),
# and the OID is 1.3.6.1.4.1.2428.20.1.29. If you follow this, you
# know that it will be compatible with what others use, and one is
# guaranteed that the OIDs are unique.
# The IANA DNS record type values are available from
# .
#
# If you define new attributes, please report them to drift@uninett.no
# to get them added of this schema.
#
# The basic record types like A, CNAME etc are defined in the cosine
# schema and not by UNINETT or FreeIPA.  This means that your LDAP server
# should use the old COSINE schema (RFC 1274) plus this one to get
# all the DNS attributes defined.
#
# Alternativelly you can use included excerpt from COSINE schema to get all
# the missing attributes.
#
#
# 389 DS requires following DN
#dn: cn=schema
#
# OpenLDAP 2.4 requires following DN + objectClass + different attribute names
# s/^olcAttributeTypes:/olcAttributeTypes:/
# s/^olcObjectClasses:/olcObjectClasses:/
dn: cn=dns,cn=schema,cn=config
objectClass: olcSchemaConfig
#
#
# COSINE schema
# comment out if your server has COSINE schema installed
#olcAttributeTypes: ( 0.9.2342.19200300.100.1.26 
# NAME 'aRecord' 
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
# EQUALITY caseIgnoreIA5Match )
#
#olcAttributeTypes: ( 0.9.2342.19200300.100.1.27 
# NAME 'mDRecord' 
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
# EQUALITY caseIgnoreIA5Match )
#
#olcAttributeTypes: ( 0.9.2342.19200300.100.1.28 
# NAME 'mXRecord' 
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
# EQUALITY caseIgnoreIA5Match )
#
#olcAttributeTypes: ( 0.9.2342.19200300.100.1.29 
# NAME 'nSRecord' 
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
# EQUALITY caseIgnoreIA5Match )
# CNAME record was originally defined as multi-value
# but we redefined it as single-value to conform with RFC 2136, section 1.1.5.
#olcAttributeTypes: ( 0.9.2342.19200300.100.1.31 
# NAME 'cNAMERecord' 
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
# EQUALITY caseIgnoreIA5Match 
# SINGLE-VALUE )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.0.0 
 NAME 'dNSTTL' 
 DESC 'An integer denoting time to live' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
 EQUALITY integerMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.0.2 
 NAME 'dNSdefaultTTL' 
 DESC 'An integer denoting default time to live, RFC 2308' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
 EQUALITY integerMatch 
 ORDERING integerOrderingMatch )
#
#
# UNINETT and FreeIPA attributes
# dnsClass attribute is in fact unsupported by bind-dyndb-ldap
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.0.1 
 NAME 'dNSClass' 
 DESC 'The class of a resource record' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.12 
 NAME 'pTRRecord' 
 DESC 'domain name pointer, RFC 1035' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.13 
 NAME 'hInfoRecord' 
 DESC 'host information, RFC 1035' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.14 
 NAME 'mInfoRecord' 
 DESC 'mailbox or mail list information, RFC 1035' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.16 
 NAME 'tXTRecord' 
 DESC 'text string, RFC 1035' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.18 
 NAME 'aFSDBRecord' 
 DESC 'for AFS Data Base location, RFC 1183' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.28 
 NAME 'aAAARecord' 
 DESC 'IPv6 address, RFC 1886' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.29 
 NAME 'LocRecord' 
 DESC 'Location, RFC 1876' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.30 
 NAME 'nXTRecord' 
 DESC 'non-existant, RFC 2535' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.33 
 NAME 'sRVRecord' 
 DESC 'service location, RFC 2782' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.35 
 NAME 'nAPTRRecord' 
 DESC 'Naming Authority Pointer, RFC 2915' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.36 
 NAME 'kXRecord' 
 DESC 'Key Exchange Delegation, RFC 2230' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.37 
 NAME 'certRecord' 
 DESC 'certificate, RFC 2538' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.38 
 NAME 'a6Record' 
 DESC 'A6 Record Type, RFC 2874' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.39 
 NAME 'dNameRecord' 
 DESC 'Non-Terminal DNS Name Redirection, RFC 6672' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.43 
 NAME 'dSRecord' 
 DESC 'Delegation Signer, RFC 3658' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.44 
 NAME 'sSHFPRecord' 
 DESC 'SSH Key Fingerprint, draft-ietf-secsh-dns-05.txt' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.51 
 NAME 'nSEC3PARAMRecord' 
 DESC 'RFC 5155' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch 
 SINGLE-VALUE ) 
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.52 NAME 'TLSARecord' 
 DESC 'DNS-Based Authentication of Named Entities - Transport Layer Security Protocol, RFC 6698' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.1.32769 
 NAME 'DLVRecord' 
 DESC 'RFC 4431: DNSSEC Lookaside Validation' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
# See https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/UnknownRecord
olcAttributeTypes: ( 1.3.6.1.4.1.2428.20.4 
 NAME 'UnknownRecord' 
 DESC 'unknown DNS record, RFC 3597' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.0 
 NAME 'idnsName' 
 DESC 'DNS FQDN' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.1 
 NAME 'idnsAllowDynUpdate' 
 DESC 'permit dynamic updates on this zone' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
 EQUALITY booleanMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.2 
 NAME 'idnsZoneActive' 
 DESC 'define if the zone is considered in use' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
 EQUALITY booleanMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.3 
 NAME 'idnsSOAmName' 
 DESC 'SOA Name' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.4 
 NAME 'idnsSOArName' 
 DESC 'SOA root Name' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.5 
 NAME 'idnsSOAserial' 
 DESC 'SOA serial number' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 
 EQUALITY numericStringMatch 
 SINGLE-VALUE ) 
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.6 
 NAME 'idnsSOArefresh' 
 DESC 'SOA refresh value' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 
 EQUALITY numericStringMatch 
 SINGLE-VALUE ) 
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.7 
 NAME 'idnsSOAretry' 
 DESC 'SOA retry value' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 
 EQUALITY numericStringMatch 
 SINGLE-VALUE ) 
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.8 
 NAME 'idnsSOAexpire' 
 DESC 'SOA expire value' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 
 EQUALITY numericStringMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.9 
 NAME 'idnsSOAminimum' 
 DESC 'SOA minimum value' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 
 EQUALITY numericStringMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.10 
 NAME 'idnsUpdatePolicy' 
 DESC 'DNS dynamic updates policy' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.11 
 NAME 'idnsAllowQuery' 
 DESC 'BIND9 allow-query ACL element' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SINGLE-VALUE ) 
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.12 
 NAME 'idnsAllowTransfer' 
 DESC 'BIND9 allow-transfer ACL element' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.13 
 NAME 'idnsAllowSyncPTR' 
 DESC 'permit synchronization of PTR records' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
 EQUALITY booleanMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.14 
 NAME 'idnsForwardPolicy' 
 DESC 'forward policy: only or first' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch 
 SINGLE-VALUE ) 
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.15 
 NAME 'idnsForwarders' 
 DESC 'list of forwarders' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.18 
 NAME 'idnsSecInlineSigning' 
 DESC 'DNSSEC in-line signing' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
 EQUALITY booleanMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.31
 NAME 'idnsServerId'
 DESC 'DNS server identifier'
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 EQUALITY caseIgnoreMatch 
 SINGLE-VALUE )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.30 
 NAME 'idnsSubstitutionVariable' 
 DESC 'User defined variable for DNS plugin' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match )
#
olcAttributeTypes: ( 2.16.840.1.113730.3.8.5.29 
 NAME 'idnsTemplateAttribute' 
 DESC 'Template attribute for dynamic attribute generation' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match )
#
olcObjectClasses: ( 2.16.840.1.113730.3.8.6.0 
 NAME 'idnsRecord' 
 DESC 'dns Record, usually a host' 
 SUP top 
 STRUCTURAL 
 MUST idnsName 
 MAY ( cn $ idnsAllowDynUpdate $ DNSTTL $ DNSClass $ ARecord $ 
       AAAARecord $ A6Record $ NSRecord $ CNAMERecord $ PTRRecord $ 
       SRVRecord $ TXTRecord $ MXRecord $ MDRecord $ HINFORecord $ 
       MINFORecord $ AFSDBRecord $ LOCRecord $ 
       NXTRecord $ NAPTRRecord $ KXRecord $ CERTRecord $ DNAMERecord $ 
       DSRecord $ SSHFPRecord $ DLVRecord $ TLSARecord $ UnknownRecord
     ) )
#
olcObjectClasses: ( 2.16.840.1.113730.3.8.6.1 
 NAME 'idnsZone' 
 DESC 'Zone class' 
 SUP idnsRecord 
 STRUCTURAL 
 MUST ( idnsName $ idnsZoneActive $ idnsSOAmName $ idnsSOArName $ 
        idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ 
        idnsSOAminimum 
      ) 
 MAY ( idnsUpdatePolicy $ idnsAllowQuery $ idnsAllowTransfer $ 
       idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ 
       idnsSecInlineSigning $ nSEC3PARAMRecord $ dNSdefaultTTL 
     ) )
#
olcObjectClasses: ( 2.16.840.1.113730.3.8.6.2 
 NAME 'idnsConfigObject' 
 DESC 'DNS global config options' 
 STRUCTURAL 
 MAY ( idnsForwardPolicy $ idnsForwarders $ idnsAllowSyncPTR ) )
#
olcObjectClasses: ( 2.16.840.1.113730.3.8.6.3 
 NAME 'idnsForwardZone' 
 DESC 'Forward Zone class' 
 SUP top 
 STRUCTURAL 
 MUST ( idnsName $ idnsZoneActive ) 
 MAY ( idnsForwarders $ idnsForwardPolicy ) )
#
olcObjectClasses: ( 2.16.840.1.113730.3.8.6.6 
 NAME 'idnsServerConfigObject' 
 DESC 'DNS server configuration' 
 SUP top 
 STRUCTURAL 
 MUST ( idnsServerId ) 
 MAY ( idnsSOAmName $ idnsForwarders $ idnsForwardPolicy $ 
       idnsSubstitutionVariable 
     ) )
#
olcObjectClasses: ( 2.16.840.1.113730.3.8.6.5 
 NAME 'idnsTemplateObject' 
 DESC 'Template object for dynamic DNS attribute generation' 
 SUP top 
 AUXILIARY 
 MUST ( idnsTemplateAttribute ) )

To add this schema to OpenLDAP I use the following command:

# ldapadd -Y EXTERNAL -H ldapi:/// -f bind9.schema.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=dns,cn=schema,cn=config"

To check, if the new schema is available just search for it:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config cn
dn: cn=schema,cn=config
cn: schema

dn: cn={0}core,cn=schema,cn=config
cn: {0}core

dn: cn={1}cosine,cn=schema,cn=config
cn: {1}cosine

dn: cn={2}nis,cn=schema,cn=config
cn: {2}nis

dn: cn={3}inetorgperson,cn=schema,cn=config
cn: {3}inetorgperson

dn: cn={4}samba,cn=schema,cn=config
cn: {4}samba

dn: cn={5}dns,cn=schema,cn=config
cn: {5}dns

The last entry shows, that is it now available.

You can now start to deploy your zones into LDAP. The following page describes the main options:

https://pagure.io/bind-dyndb-ldap

For my first zone, I use the example zone from the package here:

# vi /usr/share/doc/bind9-dyndb-ldap/example.ldif

I modified this to reflect my environment here:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b ou=dns,o=services,dc=flomain,dc=local
dn: ou=dns,o=services,dc=flomain,dc=local
ou: dns
objectClass: organizationalUnit
objectClass: top

dn: idnsName=flomain.local,ou=dns,o=services,dc=flomain,dc=local
idnsSOAmName: devil.flomain.local.
idnsSOArName: devil.flomain.local.
idnsName: flomain.local
objectClass: idnsZone
objectClass: idnsRecord
objectClass: top
idnsSOAexpire: 604800
idnsSOAminimum: 86400
aRecord: 10.104.104.10
idnsSOArefresh: 10800
idnsSOAretry: 900
idnsZoneActive: TRUE
aAAARecord: fd04:57cd:0f5d:f9c6::10
nSRecord: flomain.local.
idnsSOAserial: 1534088762

dn: idnsName=devil,idnsName=flomain.local,ou=dns,o=services,dc=flomain,dc=loca
 l
idnsName: devil
objectClass: idnsRecord
objectClass: top
cNAMERecord: flomain.local.

A reverse zone might look like this:

dn: idnsName=100.100.10.in-addr.arpa.,ou=dns,o=services,dc=flomain,dc=local
idnsSOAmName: devil.flomain.local.
idnsSOArefresh: 10800
idnsSOArName: devil.flomain.local.
nSRecord: devil.flomain.local.
idnsSOAretry: 900
idnsZoneActive: TRUE
objectClass: idnsZone
objectClass: idnsRecord
objectClass: top
idnsSOAexpire: 604800
idnsSOAminimum: 86400
idnsSOAserial: 1534092448
idnsName: 100.100.10.in-addr.arpa.

dn: idnsName=haan-router,idnsName=flomain.local,ou=dns,o=services,dc=flomain,d
 c=local
aRecord: 10.100.100.1
aAAARecord: fdf0:4d22:9d3e:bcc2::1
idnsName: haan-router
objectClass: idnsRecord
objectClass: top

Now, tell bind to use OpenLDAP as the database. Simply add the following to your configuration:

dynamic-db "my_openldap_db" {
        library "ldap.so";
        arg "uri ldap://localhost";
        arg "base ou=dns,o=services,dc=flomain,dc=local";
        arg "auth_method simple";
        arg "bind_dn cn=admin,dc=flomain,dc=local";
        arg "password Ka02629153";
};

Before you start/restart Bind enable replication on the OpenLDAP server. I use those two LDIF files for this task:

# cat syncrepl.ldif 
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
root@devil:~/ldap-scripts# ldapmodify -Y EXTERNAL -H ldapi:/// -f syncrepl.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=module{0},cn=config"

and the following to make the new module active:

# cat syncrepl_prov.ldif 
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changeType: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionLog: 100
root@devil:~/ldap-scripts# ldapmodify -Y EXTERNAL -H ldapi:/// -f syncrepl_prov.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcOverlay=syncprov,olcDatabase={1}mdb,cn=config"

Now, you can use OpenLDAP to store your zones. The cool thing, you can change the entries, without restarting bind. Due to the replication module, bind is aware of any change during runtime.

OpenLDAP: Integrate DHCP Server

For DHCP, I use the ISC-DHCP-Server. This one can also work with OpenLDAP.

To use the OpenLDAP backend for DHCP you install the required package first:

# apt-get install isc-dhcp-server-ldap

Next, you need the schema for DHCP. The package comes with a schema file. But this one is not for the online config in OpenLDAP. You can either convert it manually or use the one I converted:

dn: cn=dhcp,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: dhcp
olcAttributeTypes: {0}( 2.16.840.1.113719.1.203.4.1 NAME 'dhcpPrimaryDN' DES
 C 'The DN of the dhcpServer which is the primary server for the configurati
 on.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 S
 INGLE-VALUE )
olcAttributeTypes: {1}( 2.16.840.1.113719.1.203.4.2 NAME 'dhcpSecondaryDN' D
 ESC 'The DN of dhcpServer(s) which provide backup service for the configura
 tion.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
  )
olcAttributeTypes: {2}( 2.16.840.1.113719.1.203.4.3 NAME 'dhcpStatements' DE
 SC 'Flexible storage for specific data depending on what object this exists
  in. Like conditional statements, server parameters, etc. This allows the s
 tandard to evolve without needing to adjust the schema.' EQUALITY caseIgnor
 eIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: {3}( 2.16.840.1.113719.1.203.4.4 NAME 'dhcpRange' DESC 'T
 he starting & ending IP Addresses in the range (inclusive), separated by a 
 hyphen; if the range only contains one address, then just the address can b
 e specified with no hyphen.  Each range is defined as a separate value.' EQ
 UALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: {4}( 2.16.840.1.113719.1.203.4.5 NAME 'dhcpPermitList' DE
 SC 'This attribute contains the permit lists associated with a pool. Each p
 ermit list is defined as a separate value.' EQUALITY caseIgnoreIA5Match SYN
 TAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: {5}( 2.16.840.1.113719.1.203.4.6 NAME 'dhcpNetMask' DESC 
 'The subnet mask length for the subnet.  The mask can be easily computed fr
 om this length.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
  SINGLE-VALUE )
olcAttributeTypes: {6}( 2.16.840.1.113719.1.203.4.7 NAME 'dhcpOption' DESC '
 Encoded option values to be sent to clients.  Each value represents a singl
 e option and contains (OptionTag, Length, OptionValue) encoded in the forma
 t used by DHCP.' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.12
 1.1.26 )
olcAttributeTypes: {7}( 2.16.840.1.113719.1.203.4.8 NAME 'dhcpClassData' DES
 C 'Encoded text string or list of bytes expressed in hexadecimal, separated
  by colons.  Clients match subclasses based on matching the class data with
  the results of match or spawn with statements in the class name declaratio
 ns.' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGL
 E-VALUE )
olcAttributeTypes: {8}( 2.16.840.1.113719.1.203.4.9 NAME 'dhcpOptionsDN' DES
 C 'The distinguished name(s) of the dhcpOption objects containing the confi
 guration options provided by the server.' EQUALITY distinguishedNameMatch S
 YNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {9}( 2.16.840.1.113719.1.203.4.10 NAME 'dhcpHostDN' DESC 
 'the distinguished name(s) of the dhcpHost objects.' EQUALITY distinguished
 NameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {10}( 2.16.840.1.113719.1.203.4.11 NAME 'dhcpPoolDN' DESC
  'The distinguished name(s) of pools.' EQUALITY distinguishedNameMatch SYNT
 AX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {11}( 2.16.840.1.113719.1.203.4.12 NAME 'dhcpGroupDN' DES
 C 'The distinguished name(s)   of the groups.' EQUALITY distinguishedNameMa
 tch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {12}( 2.16.840.1.113719.1.203.4.13 NAME 'dhcpSubnetDN' DE
 SC 'The distinguished name(s) of the subnets.' EQUALITY distinguishedNameMa
 tch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {13}( 2.16.840.1.113719.1.203.4.14 NAME 'dhcpLeaseDN' DES
 C 'The distinguished name of a client address.' EQUALITY distinguishedNameM
 atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
olcAttributeTypes: {14}( 2.16.840.1.113719.1.203.4.15 NAME 'dhcpLeasesDN' DE
 SC 'The distinguished name(s) client addresses.' EQUALITY distinguishedName
 Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {15}( 2.16.840.1.113719.1.203.4.16 NAME 'dhcpClassesDN' D
 ESC 'The distinguished name(s) of a class(es) in a subclass.' EQUALITY dist
 inguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {16}( 2.16.840.1.113719.1.203.4.17 NAME 'dhcpSubclassesDN
 ' DESC 'The distinguished name(s) of subclass(es).' EQUALITY distinguishedN
 ameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {17}( 2.16.840.1.113719.1.203.4.18 NAME 'dhcpSharedNetwor
 kDN' DESC 'The distinguished name(s) of sharedNetworks.' EQUALITY distingui
 shedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {18}( 2.16.840.1.113719.1.203.4.19 NAME 'dhcpServiceDN' D
 ESC 'The DN of dhcpService object(s)which contain the configuration informa
 tion. Each dhcpServer object has this attribute identifying the DHCP config
 uration(s) that the server is associated with.' EQUALITY distinguishedNameM
 atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {19}( 2.16.840.1.113719.1.203.4.20 NAME 'dhcpVersion' DES
 C 'The version attribute of this object.' EQUALITY caseIgnoreIA5Match SYNTA
 X 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {20}( 2.16.840.1.113719.1.203.4.21 NAME 'dhcpImplementati
 on' DESC 'Description of the DHCP Server implementation e.g. DHCP Servers v
 endor.' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SI
 NGLE-VALUE )
olcAttributeTypes: {21}( 2.16.840.1.113719.1.203.4.22 NAME 'dhcpAddressState
 ' DESC 'This stores information about the current binding-status of an addr
 ess.  For dynamic addresses managed by DHCP, the values should be restricte
 d to the following: "FREE", "ACTIVE", "EXPIRED", "RELEASED", "RESET", "ABAN
 DONED", "BACKUP".  For other addresses, it SHOULD be one of the following: 
 "UNKNOWN", "RESERVED" (an address that is managed by DHCP that is reserved 
 for a specific client), "RESERVED-ACTIVE" (same as reserved, but address is
  currently in use), "ASSIGNED" (assigned manually or by some other mechanis
 m), "UNASSIGNED", "NOTASSIGNABLE".' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.
 6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {22}( 2.16.840.1.113719.1.203.4.23 NAME 'dhcpExpirationTi
 me' DESC 'This is the time the current lease for an address expires.' EQUAL
 ITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE 
 )
olcAttributeTypes: {23}( 2.16.840.1.113719.1.203.4.24 NAME 'dhcpStartTimeOfS
 tate' DESC 'This is the time of the last state change for a leased address.
 ' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE
 -VALUE )
olcAttributeTypes: {24}( 2.16.840.1.113719.1.203.4.25 NAME 'dhcpLastTransact
 ionTime' DESC 'This is the last time a valid DHCP packet was received from 
 the client.' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.
 1.24 SINGLE-VALUE )
olcAttributeTypes: {25}( 2.16.840.1.113719.1.203.4.26 NAME 'dhcpBootpFlag' D
 ESC 'This indicates whether the address was assigned via BOOTP.' EQUALITY b
 ooleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {26}( 2.16.840.1.113719.1.203.4.27 NAME 'dhcpDomainName' 
 DESC 'This is the name of the domain sent to the client by the server.  It 
 is essentially the same as the value for DHCP option 15 sent to the client,
  and represents only the domain - not the full FQDN.  To obtain the full FQ
 DN assigned to the client you must prepend the "dhcpAssignedHostName" to th
 is value with a ".".' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.1
 15.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {27}( 2.16.840.1.113719.1.203.4.28 NAME 'dhcpDnsStatus' D
 ESC 'This indicates the status of updating DNS resource records on behalf o
 f the client by the DHCP server for this address.  The value is a 16-bit bi
 tmask.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-V
 ALUE )
olcAttributeTypes: {28}( 2.16.840.1.113719.1.203.4.29 NAME 'dhcpRequestedHos
 tName' DESC 'This is the hostname that was requested by the client.' EQUALI
 TY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {29}( 2.16.840.1.113719.1.203.4.30 NAME 'dhcpAssignedHost
 Name' DESC 'This is the actual hostname that was assigned to a client. It m
 ay not be the name that was requested by the client.  The fully qualified d
 omain name can be determined by appending the value of "dhcpDomainName" (wi
 th a dot separator) to this name.' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6
 .1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {30}( 2.16.840.1.113719.1.203.4.31 NAME 'dhcpReservedForC
 lient' DESC 'The distinguished name of a "dhcpClient" that an address is re
 served for.  This may not be the same as the "dhcpAssignedToClient" attribu
 te if the address is being reassigned but the current lease has not yet exp
 ired.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
  SINGLE-VALUE )
olcAttributeTypes: {31}( 2.16.840.1.113719.1.203.4.32 NAME 'dhcpAssignedToCl
 ient' DESC 'This is the distinguished name of a "dhcpClient" that an addres
 s is currently assigned to.  This attribute is only present in the class wh
 en the address is leased.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4
 .1.1466.115.121.1.12 SINGLE-VALUE )
olcAttributeTypes: {32}( 2.16.840.1.113719.1.203.4.33 NAME 'dhcpRelayAgentIn
 fo' DESC 'If the client request was received via a relay agent, this contai
 ns information about the relay agent that was available from the DHCP reque
 st.  This is a hex-encoded option value.' EQUALITY octetStringMatch SYNTAX 
 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
olcAttributeTypes: {33}( 2.16.840.1.113719.1.203.4.34 NAME 'dhcpHWAddress' D
 ESC 'The clients hardware address that requested this IP address.' EQUALITY
  caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {34}( 2.16.840.1.113719.1.203.4.35 NAME 'dhcpHashBucketAs
 signment' DESC 'HashBucketAssignment bit map for the DHCP Server, as define
 d in DHC Load Balancing Algorithm [RFC 3074].' EQUALITY octetStringMatch SY
 NTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
olcAttributeTypes: {35}( 2.16.840.1.113719.1.203.4.36 NAME 'dhcpDelayedServi
 ceParameter' DESC 'Delay in seconds corresponding to Delayed Service Parame
 ter configuration, as defined in  DHC Load Balancing Algorithm [RFC 3074]. 
 ' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {36}( 2.16.840.1.113719.1.203.4.37 NAME 'dhcpMaxClientLea
 dTime' DESC 'Maximum Client Lead Time configuration in seconds, as defined 
 in DHCP Failover Protocol [FAILOVR]' EQUALITY integerMatch SYNTAX 1.3.6.1.4
 .1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {37}( 2.16.840.1.113719.1.203.4.38 NAME 'dhcpFailOverEndp
 ointState' DESC 'Server (Failover Endpoint) state, as defined in DHCP Failo
 ver Protocol [FAILOVR]' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466
 .115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {38}( 2.16.840.1.113719.1.203.4.39 NAME 'dhcpErrorLog' DE
 SC 'Generic error log attribute that allows logging error conditions within
  a dhcpService or a dhcpSubnet, like no IP addresses available for lease.' 
 EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VAL
 UE )
olcAttributeTypes: {39}( 2.16.840.1.113719.1.203.4.40 NAME 'dhcpLocatorDN' D
 ESC 'The DN of dhcpLocator object which contain the DNs of all DHCP configu
 ration objects. There will be a single dhcpLocator object in the tree with 
 links to all the DHCP objects in the tree' EQUALITY distinguishedNameMatch 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {40}( 2.16.840.1.113719.1.203.4.41 NAME 'dhcpKeyAlgorithm
 ' DESC 'Algorithm to generate TSIG Key' EQUALITY caseIgnoreIA5Match SYNTAX 
 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {41}( 2.16.840.1.113719.1.203.4.42 NAME 'dhcpKeySecret' D
 ESC 'Secret to generate TSIG Key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.
 4.1.1466.115.121.1.40 SINGLE-VALUE )
olcAttributeTypes: {42}( 2.16.840.1.113719.1.203.4.43 NAME 'dhcpDnsZoneServe
 r' DESC 'Master server of the DNS Zone' EQUALITY caseIgnoreIA5Match SYNTAX 
 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {43}( 2.16.840.1.113719.1.203.4.44 NAME 'dhcpKeyDN' DESC 
 'The DNs of TSIG Key to use in secure dynamic updates. In case of locator o
 bject, this will be list of TSIG keys.  In case of DHCP Service, Shared Net
 work, Subnet and DNS Zone, it will be a single key.' EQUALITY distinguished
 NameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {44}( 2.16.840.1.113719.1.203.4.45 NAME 'dhcpZoneDN' DESC
  'The DNs of DNS Zone. In case of locator object, this will be list of DNS 
 Zones in the tree. In case of DHCP Service, Shared Network and Subnet, it w
 ill be a single DNS Zone.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4
 .1.1466.115.121.1.12 )
olcAttributeTypes: {45}( 2.16.840.1.113719.1.203.4.46 NAME 'dhcpFailOverPrim
 aryServer' DESC 'IP address or DNS name of the server playing primary role 
 in DHC Load Balancing and Fail over.' EQUALITY caseIgnoreIA5Match SYNTAX 1.
 3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: {46}( 2.16.840.1.113719.1.203.4.47 NAME 'dhcpFailOverSeco
 ndaryServer' DESC 'IP address or DNS name of the server playing secondary r
 ole in DHC Load Balancing and Fail over.' EQUALITY caseIgnoreIA5Match SYNTA
 X 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: {47}( 2.16.840.1.113719.1.203.4.48 NAME 'dhcpFailOverPrim
 aryPort' DESC 'Port on which primary server listens for connections from it
 s fail over peer (secondary server)' EQUALITY integerMatch SYNTAX 1.3.6.1.4
 .1.1466.115.121.1.27 )
olcAttributeTypes: {48}( 2.16.840.1.113719.1.203.4.49 NAME 'dhcpFailOverSeco
 ndaryPort' DESC 'Port on which secondary server listens for connections fro
 m its fail over peer (primary server)' EQUALITY integerMatch SYNTAX 1.3.6.1
 .4.1.1466.115.121.1.27 )
olcAttributeTypes: {49}( 2.16.840.1.113719.1.203.4.50 NAME 'dhcpFailOverResp
 onseDelay' DESC 'Maximum response time in seconds, before Server assumes th
 at connection to fail over peer has failed' EQUALITY integerMatch SYNTAX 1.
 3.6.1.4.1.1466.115.121.1.27 )
olcAttributeTypes: {50}( 2.16.840.1.113719.1.203.4.51 NAME 'dhcpFailOverUnac
 kedUpdates' DESC 'Number of BNDUPD messages that server can send before it 
 receives BNDACK from its fail over peer' EQUALITY integerMatch SYNTAX 1.3.6
 .1.4.1.1466.115.121.1.27 )
olcAttributeTypes: {51}( 2.16.840.1.113719.1.203.4.52 NAME 'dhcpFailOverSpli
 t' DESC 'Split between the primary and secondary servers for fail over purp
 ose' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
olcAttributeTypes: {52}( 2.16.840.1.113719.1.203.4.53 NAME 'dhcpFailOverLoad
 BalanceTime' DESC 'Cutoff time in seconds, after which load balance is disa
 bled' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
olcAttributeTypes: {53}( 2.16.840.1.113719.1.203.4.54 NAME 'dhcpFailOverPeer
 DN' DESC 'The DNs of Fail over peers. In case of locator object, this will 
 be list of fail over peers in the tree. In case of Subnet and pool, it will
  be a single Fail Over Peer' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1
 .4.1.1466.115.121.1.12 )
olcAttributeTypes: {54}( 2.16.840.1.113719.1.203.4.55 NAME 'dhcpServerDN' DE
 SC 'List of all  DHCP Servers in the tree. Used by dhcpLocatorObject' EQUAL
 ITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
olcAttributeTypes: {55}( 2.16.840.1.113719.1.203.4.56 NAME 'dhcpComments' DE
 SC 'Generic attribute that allows coments  within any DHCP object' EQUALITY
  caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcAttributeTypes: {56}( 2.16.840.1.113719.1.203.4.57 NAME 'dhcpClientId' DE
 SC 'client Identifier.' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466
 .115.121.1.26 )
olcAttributeTypes: {57}( 2.16.840.1.113719.1.203.4.58 NAME 'dhcpRange6' DESC
  'The starting & ending IP Addresses in the range (inclusive), separated by
  a hyphen; if the range only contains one address, then just the address ca
 n be specified with no hyphen.  Each range is defined as a separate value.'
  EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcObjectClasses: {0}( 2.16.840.1.113719.1.203.6.1 NAME 'dhcpService' DESC '
 Service object that represents the actual DHCP Service configuration. This 
 is a container object.' SUP top STRUCTURAL MUST cn MAY ( dhcpPrimaryDN $ dh
 cpSecondaryDN $ dhcpServerDN $ dhcpSharedNetworkDN $ dhcpSubnetDN $ dhcpGro
 upDN $ dhcpHostDN $ dhcpClassesDN $ dhcpOptionsDN $ dhcpZoneDN $ dhcpKeyDN 
 $ dhcpFailOverPeerDN $ dhcpStatements $ dhcpComments $ dhcpOption ) )
olcObjectClasses: {1}( 2.16.840.1.113719.1.203.6.2 NAME 'dhcpSharedNetwork' 
 DESC 'This stores configuration information for a shared network.' SUP top 
 STRUCTURAL MUST cn MAY ( dhcpSubnetDN $ dhcpPoolDN $ dhcpOptionsDN $ dhcpZo
 neDN $ dhcpStatements $ dhcpComments $ dhcpOption ) X-NDS_CONTAINMENT 'dhcp
 Service' )
olcObjectClasses: {2}( 2.16.840.1.113719.1.203.6.3 NAME 'dhcpSubnet' DESC 'T
 his class defines a subnet. This is a container object.' SUP top STRUCTURAL
  MUST ( cn $ dhcpNetMask ) MAY ( dhcpRange $ dhcpPoolDN $ dhcpGroupDN $ dhc
 pHostDN $ dhcpClassesDN $ dhcpLeasesDN $ dhcpOptionsDN $ dhcpZoneDN $ dhcpK
 eyDN $ dhcpFailOverPeerDN $ dhcpStatements $ dhcpComments $ dhcpOption ) X-
 NDS_CONTAINMENT ( 'dhcpService' 'dhcpSharedNetwork' ) )
olcObjectClasses: {3}( 2.16.840.1.113719.1.203.6.4 NAME 'dhcpPool' DESC 'Thi
 s stores configuration information about a pool.' SUP top STRUCTURAL MUST (
  cn $ dhcpRange ) MAY ( dhcpClassesDN $ dhcpPermitList $ dhcpLeasesDN $ dhc
 pOptionsDN $ dhcpZoneDN $ dhcpKeyDN $ dhcpStatements $ dhcpComments $ dhcpO
 ption ) X-NDS_CONTAINMENT ( 'dhcpSubnet' 'dhcpSharedNetwork' ) )
olcObjectClasses: {4}( 2.16.840.1.113719.1.203.6.5 NAME 'dhcpGroup' DESC 'Gr
 oup object that lists host DNs and parameters. This is a container object.'
  SUP top STRUCTURAL MUST cn MAY ( dhcpHostDN $ dhcpOptionsDN $ dhcpStatemen
 ts $ dhcpComments $ dhcpOption ) X-NDS_CONTAINMENT ( 'dhcpSubnet' 'dhcpServ
 ice' ) )
olcObjectClasses: {5}( 2.16.840.1.113719.1.203.6.6 NAME 'dhcpHost' DESC 'Thi
 s represents information about a particular client' SUP top STRUCTURAL MUST
  cn MAY ( dhcpLeaseDN $ dhcpHWAddress $ dhcpOptionsDN $ dhcpStatements $ dh
 cpComments $ dhcpOption $ dhcpClientId ) X-NDS_CONTAINMENT ( 'dhcpService' 
 'dhcpSubnet' 'dhcpGroup' ) )
olcObjectClasses: {6}( 2.16.840.1.113719.1.203.6.7 NAME 'dhcpClass' DESC 'Re
 presents information about a collection of related clients.' SUP top STRUCT
 URAL MUST cn MAY ( dhcpSubClassesDN $ dhcpOptionsDN $ dhcpStatements $ dhcp
 Comments $ dhcpOption ) X-NDS_CONTAINMENT ( 'dhcpService' 'dhcpSubnet' ) )
olcObjectClasses: {7}( 2.16.840.1.113719.1.203.6.8 NAME 'dhcpSubClass' DESC 
 'Represents information about a collection of related classes.' SUP top STR
 UCTURAL MUST cn MAY ( dhcpClassData $ dhcpOptionsDN $ dhcpStatements $ dhcp
 Comments $ dhcpOption ) X-NDS_CONTAINMENT 'dhcpClass' )
olcObjectClasses: {8}( 2.16.840.1.113719.1.203.6.9 NAME 'dhcpOptions' DESC '
 Represents information about a collection of options defined.' SUP top AUXI
 LIARY MUST cn MAY ( dhcpOption $ dhcpComments ) X-NDS_CONTAINMENT ( 'dhcpSe
 rvice' 'dhcpSharedNetwork' 'dhcpSubnet' 'dhcpPool' 'dhcpGroup' 'dhcpHost' '
 dhcpClass' ) )
olcObjectClasses: {9}( 2.16.840.1.113719.1.203.6.10 NAME 'dhcpLeases' DESC '
 This class represents an IP Address, which may or may not have been leased.
 ' SUP top STRUCTURAL MUST ( cn $ dhcpAddressState ) MAY ( dhcpExpirationTim
 e $ dhcpStartTimeOfState $ dhcpLastTransactionTime $ dhcpBootpFlag $ dhcpDo
 mainName $ dhcpDnsStatus $ dhcpRequestedHostName $ dhcpAssignedHostName $ d
 hcpReservedForClient $ dhcpAssignedToClient $ dhcpRelayAgentInfo $ dhcpHWAd
 dress ) X-NDS_CONTAINMENT ( 'dhcpService' 'dhcpSubnet' 'dhcpPool' ) )
olcObjectClasses: {10}( 2.16.840.1.113719.1.203.6.11 NAME 'dhcpLog' DESC 'Th
 is is the object that holds past information about the IP address. The cn i
 s the time/date stamp when the address was assigned or released, the addres
 s state at the time, if the address was assigned or released.' SUP top STRU
 CTURAL MUST cn MAY ( dhcpAddressState $ dhcpExpirationTime $ dhcpStartTimeO
 fState $ dhcpLastTransactionTime $ dhcpBootpFlag $ dhcpDomainName $ dhcpDns
 Status $ dhcpRequestedHostName $ dhcpAssignedHostName $ dhcpReservedForClie
 nt $ dhcpAssignedToClient $ dhcpRelayAgentInfo $ dhcpHWAddress $ dhcpErrorL
 og ) X-NDS_CONTAINMENT ( 'dhcpLeases' 'dhcpPool' 'dhcpSubnet' 'dhcpSharedNe
 twork' 'dhcpService' ) )
olcObjectClasses: {11}( 2.16.840.1.113719.1.203.6.12 NAME 'dhcpServer' DESC 
 'DHCP Server Object' SUP top STRUCTURAL MUST cn MAY ( dhcpServiceDN $ dhcpL
 ocatorDN $ dhcpVersion $ dhcpImplementation $ dhcpHashBucketAssignment $ dh
 cpDelayedServiceParameter $ dhcpMaxClientLeadTime $ dhcpFailOverEndpointSta
 te $ dhcpStatements $ dhcpComments $ dhcpOption ) X-NDS_CONTAINMENT ( 'orga
 nization' 'organizationalunit' 'domain' ) )
olcObjectClasses: {12}( 2.16.840.1.113719.1.203.6.13 NAME 'dhcpTSigKey' DESC
  'TSIG key for secure dynamic updates' SUP top STRUCTURAL MUST ( cn $ dhcpK
 eyAlgorithm $ dhcpKeySecret ) MAY dhcpComments X-NDS_CONTAINMENT ( 'dhcpSer
 vice' 'dhcpSharedNetwork' 'dhcpSubnet' ) )
olcObjectClasses: {13}( 2.16.840.1.113719.1.203.6.14 NAME 'dhcpDnsZone' DESC
  'DNS Zone for updating leases' SUP top STRUCTURAL MUST ( cn $ dhcpDnsZoneS
 erver ) MAY ( dhcpKeyDN $ dhcpComments ) X-NDS_CONTAINMENT ( 'dhcpService' 
 'dhcpSharedNetwork' 'dhcpSubnet' ) )
olcObjectClasses: {14}( 2.16.840.1.113719.1.203.6.15 NAME 'dhcpFailOverPeer'
  DESC 'This class defines the Fail over peer' SUP top STRUCTURAL MUST ( cn 
 $ dhcpFailOverPrimaryServer $ dhcpFailOverSecondaryServer $ dhcpFailoverPri
 maryPort $ dhcpFailOverSecondaryPort ) MAY ( dhcpFailOverResponseDelay $ dh
 cpFailOverUnackedUpdates $ dhcpMaxClientLeadTime $ dhcpFailOverSplit $ dhcp
 HashBucketAssignment $ dhcpFailOverLoadBalanceTime $ dhcpComments ) X-NDS_C
 ONTAINMENT ( 'dhcpService' 'dhcpSharedNetwork' 'dhcpSubnet' ) )
olcObjectClasses: {15}( 2.16.840.1.113719.1.203.6.16 NAME 'dhcpLocator' DESC
  'Locator object for DHCP configuration in the tree. There will be a single
  dhcpLocator object in the tree with links to all the DHCP objects in the t
 ree' SUP top STRUCTURAL MUST cn MAY ( dhcpServiceDN $ dhcpServerDN $ dhcpSh
 aredNetworkDN $ dhcpSubnetDN $ dhcpPoolDN $ dhcpGroupDN $ dhcpHostDN $ dhcp
 ClassesDN $ dhcpKeyDN $ dhcpZoneDN $ dhcpFailOverPeerDN $ dhcpOption $ dhcp
 Comments ) X-NDS_CONTAINMENT ( 'organization' 'organizationalunit' 'domain'
  ) )
olcObjectClasses: {16}( 2.16.840.1.113719.1.203.6.17 NAME 'dhcpSubnet6' DESC
  'This class defines an IPv6 subnet. This is a container object.' SUP top S
 TRUCTURAL MUST cn MAY ( dhcpRange6 $ dhcpPoolDN $ dhcpGroupDN $ dhcpHostDN 
 $ dhcpClassesDN $ dhcpLeasesDN $ dhcpOptionsDN $ dhcpZoneDN $ dhcpKeyDN $ d
 hcpFailOverPeerDN $ dhcpStatements $ dhcpComments $ dhcpOption $ dhcpPermit
 List ) X-NDS_CONTAINMENT ( 'dhcpService' 'dhcpSharedNetwork' ) )
olcObjectClasses: {17}( 2.16.840.1.113719.1.203.6.18 NAME 'dhcpPool6' DESC '
 This stores configuration information about an IPv6 pool.' SUP top STRUCTUR
 AL MUST ( cn $ dhcpRange6 ) MAY ( dhcpClassesDN $ dhcpPermitList $ dhcpLeas
 esDN $ dhcpOptionsDN $ dhcpZoneDN $ dhcpKeyDN $ dhcpStatements $ dhcpCommen
 ts $ dhcpOption ) X-NDS_CONTAINMENT ( 'dhcpSubnet6' 'dhcpSharedNetwork' ) )

The above one is converted from the schema, which comes with Debian. Import the schema to OpenLDAP:

# ldapadd -Y EXTERNAL -H ldapi:/// -f dhcp_schema.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=dhcp,cn=schema,cn=config"

To check, if the schema is there, use this command:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config cn
dn: cn=schema,cn=config
cn: schema

dn: cn={0}core,cn=schema,cn=config
cn: {0}core

dn: cn={1}cosine,cn=schema,cn=config
cn: {1}cosine

dn: cn={2}nis,cn=schema,cn=config
cn: {2}nis

dn: cn={3}inetorgperson,cn=schema,cn=config
cn: {3}inetorgperson

dn: cn={4}samba,cn=schema,cn=config
cn: {4}samba

dn: cn={5}dns,cn=schema,cn=config
cn: {5}dns

dn: cn={6}dhcp,cn=schema,cn=config
cn: {6}dhcp

The last entry is the new DHCP schema.

We can now start to populate the objects to OpenLDAP. My entry point is again below “o=services,dc=flomain,dc=local”. Here I create a new ou dhcp:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b ou=dhcp,o=services,dc=flomain,dc=local
dn: ou=dhcp,o=services,dc=flomain,dc=local
ou: dhcp
objectClass: organizationalUnit
objectClass: top

All the DHCP related stuff will go into this branch. Let’s start with the DHCP server configuration:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b ou=dhcp,o=services,dc=flomain,dc=local
dn: ou=dhcp,o=services,dc=flomain,dc=local
ou: dhcp
objectClass: organizationalUnit
objectClass: top

dn: cn=server,ou=dhcp,o=services,dc=flomain,dc=local
cn: server
objectClass: dhcpServer
objectClass: top

We need to modify this entry later. The cn for the “dhcpServer” object is the name of the server. If you have multiple, make them unique.

Next step, is to create the service:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b ou=dhcp,o=services,dc=flomain,dc=local
dn: ou=dhcp,o=services,dc=flomain,dc=local
ou: dhcp
objectClass: organizationalUnit
objectClass: top

dn: cn=config,ou=dhcp,o=services,dc=flomain,dc=local
cn: config
objectClass: dhcpService
objectClass: top
objectClass: dhcpOptions
dhcpPrimaryDN: cn=server,ou=dhcp,o=services,dc=flomain,dc=local
dhcpStatements: default-lease-time 691200
dhcpStatements: max-lease-time 1382400
dhcpStatements: ddns-update-style none
dhcpStatements: authoritative
dhcpOption: domain-name "flomain.local"
dhcpOption: domain-name-servers 10.104.104.10

I think the “dhcpStatements” and “dhcpOption” values are well known to people, who have configured the DHCP server with a config file already.

Now, we need to bind the server to this services as well:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=server,ou=dhcp,o=services,dc=flomain,dc=local
dn: cn=server,ou=dhcp,o=services,dc=flomain,dc=local
cn: server
objectClass: dhcpServer
objectClass: top
dhcpServiceDN: cn=config,ou=dhcp,o=services,dc=flomain,dc=local

The attribute “dhcpServiceDN” is new.

We can now start to populate the subnets. First, we start with the one for the local interface. This one is just there to let the server start without issues, but will not serve IP addresses:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config,ou=dhcp,o=services,dc=flomain,dc=local
dn: cn=config,ou=dhcp,o=services,dc=flomain,dc=local
cn: config
objectClass: dhcpService
objectClass: top
objectClass: dhcpOptions
dhcpPrimaryDN: cn=server,ou=dhcp,o=services,dc=flomain,dc=local
dhcpStatements: default-lease-time 691200
dhcpStatements: max-lease-time 1382400
dhcpStatements: ddns-update-style none
dhcpStatements: authoritative
dhcpOption: domain-name "flomain.local"
dhcpOption: domain-name-servers 10.104.104.10

dn: cn=10.104.104.0,cn=config,ou=dhcp,o=services,dc=flomain,dc=local
dhcpNetMask: 24
cn: 10.104.104.0
objectClass: dhcpSubnet
objectClass: top

I include the service object as well, as this, together with the subnets creates the whole config. I add 2 other subnets as well, which I need for my network to work properly. One for my users and one for my Aruba Campus AP’s. This one also includes the option 43 for those AP’s, to find the Aruba Controller. Below is my full config in OpenLDAP for DHCP:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config,ou=dhcp,o=services,dc=flomain,dc=local
dn: cn=config,ou=dhcp,o=services,dc=flomain,dc=local
cn: config
objectClass: dhcpService
objectClass: top
objectClass: dhcpOptions
dhcpPrimaryDN: cn=server,ou=dhcp,o=services,dc=flomain,dc=local
dhcpStatements: default-lease-time 691200
dhcpStatements: max-lease-time 1382400
dhcpStatements: ddns-update-style none
dhcpStatements: authoritative
dhcpOption: domain-name "flomain.local"
dhcpOption: domain-name-servers 10.104.104.10
dhcpOption: master code 43 = ip-address

dn: cn=192.168.2.0,cn=config,ou=dhcp,o=services,dc=flomain,dc=local
dhcpOption: routers 192.168.2.1
dhcpOption: subnet-mask 255.255.255.0
dhcpOption: domain-search "flomain.local"
dhcpOption: domain-name "flomain.local"
dhcpOption: domain-name-servers 10.104.104.10
dhcpNetMask: 24
cn: 192.168.2.0
objectClass: dhcpSubnet
objectClass: top
dhcpRange: 192.168.2.2 192.168.2.254
dhcpComments: VLAN 1 range, will be removed in the future

dn: cn=10.104.104.0,cn=config,ou=dhcp,o=services,dc=flomain,dc=local
dhcpNetMask: 24
cn: 10.104.104.0
objectClass: dhcpSubnet
objectClass: top
dhcpComments: Local Subnet to let the DHCP start

dn: cn=10.106.106.0,cn=config,ou=dhcp,o=services,dc=flomain,dc=local
dhcpOption: subnet-mask 255.255.255.0
dhcpOption: domain-search "flomain.local"
dhcpOption: domain-name "flomain.local"
dhcpOption: domain-name-servers 10.104.104.10
dhcpOption: routers 10.106.106.1
dhcpComments: VLAN 106, CAP Management
dhcpNetMask: 24
cn: 10.106.106.0
objectClass: dhcpSubnet
objectClass: top
dhcpRange: 10.106.106.10 10.106.106.200

dn: cn=ArubaAP-Class,cn=config,ou=dhcp,o=services,dc=flomain,dc=local
dhcpStatements: match option vendor-class-identifier
dhcpComments: Aruba AP DHCP Class for Option 43
cn: ArubaAP-Class
objectClass: dhcpClass
objectClass: top

dn: cn=ArubaAP,cn=10.106.106.0,cn=config,ou=dhcp,o=services,dc=flomain,dc=loca
 l
dhcpOption: vendor-class-identifier "ArubaAP"
dhcpOption: master 10.100.100.50
cn: ArubaAP
objectClass: dhcpSubClass
objectClass: top
dhcpClassData: ArubaAP-Class

Below is my config for the dhcpd daemon:

#dhcpd.conf
#
# LDAP config

ldap-server                 "localhost";
ldap-port                   389;
# We do an anonymous bind
# ldap-username             "cn=directorymanagerloginname";
# ldap-password             "mypassword";
ldap-base-dn                "ou=dhcp,o=services,dc=flomain,dc=local";
ldap-method                 static;
ldap-debug-file             "/var/log/dhcp-ldap-startup.log";
ldap-dhcp-server-cn         "server";

Restart the daemon and check the LDAP debug file:

# cat /var/log/dhcp-ldap-startup.log 
default-lease-time 691200;
max-lease-time 1382400;
ddns-update-style none;
authoritative;
option domain-name "flomain.local";
option domain-name-servers 10.104.104.10;
option master code 43 = ip-address;
class "ArubaAP-Class" {
match option vendor-class-identifier;
}
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.2 192.168.2.254;
option routers 192.168.2.1;
option subnet-mask 255.255.255.0;
option domain-search "flomain.local";
option domain-name "flomain.local";
option domain-name-servers 10.104.104.10;
}
subnet 10.104.104.0 netmask 255.255.255.0 {
}
subnet 10.106.106.0 netmask 255.255.255.0 {
range 10.106.106.10 10.106.106.200;
option subnet-mask 255.255.255.0;
option domain-search "flomain.local";
option domain-name "flomain.local";
option domain-name-servers 10.104.104.10;
option routers 10.106.106.1;
subclass "ArubaAP-Class" "ArubaAP" {
option vendor-class-identifier "ArubaAP";
option master 10.100.100.50;
}
}

If this is the config you expect, you have done a great job.

If you change something in OpenLDAP, you need to restart the DHCP server, to read the new options.

OpenLDAP: Update Bind from DHCP

This part describes the configuration to update dynamic IP leases from the DHCP server to the DNS server.

First, you should create a key, which is used for the secure communication between the DHCP server and the DNS server. I use the “dnssec-keygen” tool. The “-a” defines the algorithm, “-b” the key size and “-n” the nametype. For dynamic dns updates, this value needs to be host, followed by the hostname:

# dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST test.flomain.local.
Ktest.flomain.local.+165+51489

This creates two files in the current directory:

# ls -l Ktest.flomain.local.+165+51489.*
-rw-r--r-- 1 root root 127 Aug 20 20:35 Ktest.flomain.local.+165+51489.key
-rw------- 1 root root 232 Aug 20 20:35 Ktest.flomain.local.+165+51489.private

The secret key is in both of them:

# cat Ktest.flomain.local.+165+51489.private 
Private-key-format: v1.3
Algorithm: 165 (HMAC_SHA512)
Key: D19nAcL6JLhVoNldTvcZ7B3Ni77Yc4hkhG59kNi0chz8owyeYEFl53S62YAgDh5yeKJ0SAB+fZ9OtyRIkAmsGw==
Bits: AAA=
Created: 20180820183533
Publish: 20180820183533
Activate: 20180820183533
root@devil:~# cat Ktest.flomain.local.+165+51489.key 
test.flomain.local. IN KEY 512 3 165 D19nAcL6JLhVoNldTvcZ7B3Ni77Yc4hkhG59kNi0chz8owyeYEFl53S6 2YAgDh5yeKJ0SAB+fZ9OtyRIkAmsGw==

The line with “key” is the secret key. Copy this in this file:

cat /etc/bind/rndc.key 
key "test.flomain.local" {
        algorithm hmac-sha512;
        secret "D19nAcL6JLhVoNldTvcZ7B3Ni77Yc4hkhG59kNi0chz8owyeYEFl53S62YAgDh5yeKJ0SAB+fZ9OtyRIkAmsGw==";
};

The string in quotes is used to reference the secret. This should be the same value as after the “-n HOST” part form the command above.

Now, include the key in the bind configuration and configure the key usage for updates:

# cat /etc/bind/named.conf.local 
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

dynamic-db "my_openldap_db" {
        library "ldap.so";
        arg "uri ldap://localhost";
        arg "base ou=dns,o=services,dc=flomain,dc=local";
        arg "auth_method simple";
        arg "bind_dn cn=admin,dc=flomain,dc=local";
        arg "password Ka02629153";
};

include "/etc/bind/rndc.key";

The last line includes the key file. Now, add the following line to the “named.conf.options” file in the “options” section:

allow-update { key test.flomain.local; };

You need to do this globally, as the bind schema for OpenLDAP does not allow this kind of configuration in the zone. Normally, you would have this option in the zone section of your config.

Now, update the zone object in OpenLDAP to look like this:

# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b idnsName=flomain.local,ou=dns,o=services,dc=flomain,dc=local
dn: idnsName=flomain.local,ou=dns,o=services,dc=flomain,dc=local
idnsSOAmName: devil.flomain.local.
idnsSOArName: devil.flomain.local.
idnsName: flomain.local
objectClass: idnsZone
objectClass: idnsRecord
objectClass: top
idnsSOAexpire: 604800
idnsSOAminimum: 86400
aRecord: 10.104.104.10
idnsSOArefresh: 10800
idnsSOAretry: 900
idnsZoneActive: TRUE
aAAARecord: fd04:57cd:0f5d:f9c6::10
nSRecord: flomain.local.
idnsSOAserial: 1534151701
idnsAllowDynUpdate: TRUE
idnsUpdatePolicy: grant test.flomain.local zonesub ANY;
idnsAllowSyncPTR: TRUE

The important parts are the last 3 ones:

idnsAllowDynUpdate: TRUE
idnsUpdatePolicy: grant test.flomain.local zonesub ANY;
idnsAllowSyncPTR: TRUE

The first one allows dynamic updates for that zone, the second one specifies the policy and the last one enables the reverse lookup creation.

Do this for all zones with dynamic updates. Afterward, the DNS part is done.

Now let’s do the DHCP part.

Change the DHCP service object to look like this:

dn: cn=config,ou=dhcp,o=services,dc=flomain,dc=local
cn: config
objectClass: dhcpService
objectClass: top
objectClass: dhcpOptions
dhcpPrimaryDN: cn=server,ou=dhcp,o=services,dc=flomain,dc=local
dhcpStatements: default-lease-time 691200
dhcpStatements: max-lease-time 1382400
dhcpStatements: authoritative
dhcpStatements: ddns-update-style interim
dhcpStatements: update-static-leases on
dhcpOption: domain-name "flomain.local"
dhcpOption: domain-name-servers 10.104.104.10
dhcpOption: master code 43 = ip-address

The following two lines are important:

dhcpStatements: ddns-update-style interim
dhcpStatements: update-static-leases on

Next, you need to create a “dhcpTSigKey” object. This object holds the key, generated with “dnssec-keygen” tool:

dn: cn=test.flomain.local,cn=config,ou=dhcp,o=services,dc=flomain,dc=local
dhcpKeyAlgorithm: hmac-sha512
objectClass: dhcpTSigKey
objectClass: top
cn: test.flomain.local
dhcpKeySecret:D19nAcL6JLhVoNldTvcZ7B3Ni77Yc4hkhG59kNi0chz8owyeYEFl53S62YAgDh5yeKJ0SAB+fZ9OtyRIkAmsGw==

The last step is to create a DNS zone:

dn: cn=flomain.local.,cn=config,ou=dhcp,o=services,dc=flomain,dc=local
cn: flomain.local.
objectClass: dhcpDnsZone
objectClass: top
dhcpDnsZoneServer: 127.0.0.1
dhcpKeyDN: cn=test.flomain.local,cn=config,ou=dhcp,o=services,dc=flomain,dc=l
 ocal

This “dhcpDnsZone” object references the “dhcpTSigKey” object. And whenever an IP for this zone gets an update, this update is sent to the DNS server as well.

You can see  a successful update in the Bind logs:

0-Aug-2018 21:17:25.883 update: info: client 127.0.0.1#54490/key test.flomain.local: updating zone 'flomain.local/IN': adding an RR at 'Netatmo-Personal-Weather-Station.flomain.local' A 192.168.2.108
20-Aug-2018 21:17:25.885 update: info: client 127.0.0.1#54490/key test.flomain.local: updating zone 'flomain.local/IN': adding an RR at 'Netatmo-Personal-Weather-Station.flomain.local' TXT "0031f4153610e090a639d5c80be22fc76f"
20-Aug-2018 21:17:25.971 notify: info: zone flomain.local/IN: sending notifies (serial 1534792646)
20-Aug-2018 21:17:25.972 notify: info: zone 2.168.192.in-addr.arpa/IN: sending notifies (serial 1534792645)
20-Aug-2018 21:17:25.972 notify: info: client 10.104.104.10#46481: received notify for zone 'flomain.local'
20-Aug-2018 21:17:26.472 notify: info: client fd04:57cd:f5d:f9c6::10#58608: received notify for zone 'flomain.local'
20-Aug-2018 21:17:30.971 notify: info: zone flomain.local/IN: sending notifies (serial 1534792646)
20-Aug-2018 21:17:30.972 notify: info: client 10.104.104.10#59458: received notify for zone 'flomain.local'
20-Aug-2018 21:17:31.471 notify: info: client fd04:57cd:f5d:f9c6::10#50364: received notify for zone 'flomain.local'
20-Aug-2018 21:17:34.865 update: info: client 127.0.0.1#54490/key test.flomain.local: updating zone 'flomain.local/IN': deleting an RR at Netatmo-Personal-Weather-Station.flomain.local A
20-Aug-2018 21:17:34.906 notify: info: zone 2.168.192.in-addr.arpa/IN: sending notifies (serial 1534792654)
20-Aug-2018 21:17:34.907 update: info: client 127.0.0.1#54490/key test.flomain.local: updating zone 'flomain.local/IN': deleting an RR at Netatmo-Personal-Weather-Station.flomain.local TXT
20-Aug-2018 21:17:35.971 notify: info: zone flomain.local/IN: sending notifies (serial 1534792648)
20-Aug-2018 21:17:35.971 notify: info: client 10.104.104.10#58622: received notify for zone 'flomain.local'
20-Aug-2018 21:17:36.471 notify: info: client fd04:57cd:f5d:f9c6::10#57899: received notify for zone 'flomain.local'

This is an update for the Zone flomain.local. The client is my weather station, which comes online for a very short time, so you see the first entries, where the station is added to the DNS zone, and seconds later, after the station sends the DHCP release, the entry is removed again. Due to the pointer sync, the reverse zone is updated as well.

That’s it. The last important point for me is to enable monitoring with Munin.

OpenLDAP: Monitoring with Munin

To start monitoring with OpenLDAP and online config, you need to load the monitoring module first.

Check for the next free sequence number:

# ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=module{0},cn=config
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=module{0},cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}syncprov

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

In my case it is {2}, as {1} is already used by the “syncprov” module. So, create the following file:

# cat monitoring.ldif 
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {2}back_monitor

Replace the {2} with your sequence number and execute the LDIF file:

# ldapmodify -Y EXTERNAL -H ldapi:/// -f monitoring.ldif

Afterward, create a new user for monitoring purposes. The first step is to create a password for that user:

s# slappasswd -s secret_password
{SSHA}GkbsH9EDpeydBvGqAvWEgwxkoPXZjW73

Using this password create the following file:

# cat monitoring-user.ldif 
dn: cn=monitor,dc=flomain,dc=local
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: monitor
description: LDAP monitor
userPassword:{SSHA}GkbsH9EDpeydBvGqAvWEgwxkoPXZjW73

Add the new user to LDAP:

# ldapadd -x -D cn=admin,dc=flomain,dc=local -w secre_password_from_admin -f monitoring-user.ldif 
adding new entry "cn=monitor,dc=flomain,dc=local"

Afterward, add the monitoring database by creating this file:

# cat monitor-database.ldif 
dn: olcDatabase={2}Monitor,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMonitorConfig
olcDatabase: {2}Monitor
olcAccess: {0}to dn.subtree="cn=Monitor" by dn.base="cn=monitor,dc=flomain,dc=local" read by * none

And add the database to OpenLDAP:

# ldapadd -Y EXTERNAL -H ldapi:/// -f monitor-database.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase={2}Monitor,cn=config"

I assume Munin is already up and running. to make sure you have all the needed libraries, run this command:

# apt-get install munin-node libnet-ldap-perl

and add the following lines to your munin config (/etc/munin/plugin-conf.d/munin-node):

[slapd_*]
env.server 127.0.0.1
env.binddn cn=monitor,dc=flomain,dc=local
env.bindpw secret_password

The last step is to change into the plugins directory and create the needed symlinks:

# cd /etc/munin/plugins/
root@devil:/etc/munin/plugins# ln -s /usr/share/munin/plugins/slapd_ slapd_statistics_bytes
root@devil:/etc/munin/plugins# ln -s /usr/share/munin/plugins/slapd_ slapd_statistics_pdu
root@devil:/etc/munin/plugins# ln -s /usr/share/munin/plugins/slapd_ slapd_statistics_referrals
root@devil:/etc/munin/plugins# ln -s /usr/share/munin/plugins/slapd_ slapd_operations_diff
root@devil:/etc/munin/plugins# ln -s /usr/share/munin/plugins/slapd_ slapd_statistics_entries
root@devil:/etc/munin/plugins# ln -s /usr/share/munin/plugins/slapd_ slapd_connections
root@devil:/etc/munin/plugins# ln -s /usr/share/munin/plugins/slapd_ slapd_waiters
root@devil:/etc/munin/plugins# ln -s /usr/share/munin/plugins/slapd_ slapd_operations

Now, restart munin and wait for the result:

# /etc/init.d/munin-node restart
OpenLDAP - Monitoring with Munin

OpenLDAP – Monitoring with Munin

As you can see above, the OpenLDAP server in my LAB is not heavily used 🙂

 

How do you manage your services in your LAB, like user database, DNS and DHCP?

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post Using Linux with OpenLDAP for User, DHCP and DNS appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/09/using-linux-with-openldap-for-user-dhcp-and-dns/feed/ 0 1094
Aruba InstantAP Mesh – IAP Mesh https://www.flomain.de/2018/08/aruba-instantap-mesh-iap-mesh/ https://www.flomain.de/2018/08/aruba-instantap-mesh-iap-mesh/#respond Wed, 29 Aug 2018 11:30:07 +0000 https://www.flomain.de/?p=1114 During the last month, I had several projects which use Aruba InstantAP Mesh. So I would like to share my experience with Aruba InstantAP Mesh. IAP Mesh is a technology to either connect remote IAP’s to the cluster, if no ethernet connection is available, or to connect different networks with each other when no wired […]

The post Aruba InstantAP Mesh – IAP Mesh appeared first on Flomain Networking.

]]>
During the last month, I had several projects which use Aruba InstantAP Mesh. So I would like to share my experience with Aruba InstantAP Mesh.

IAP Mesh is a technology to either connect remote IAP’s to the cluster, if no ethernet connection is available, or to connect different networks with each other when no wired connection is available.

InstantAP Mesh – Basics

IAP mesh is very simple and easy to configure. The setup consists of two components, the Mesh Portal, which has a wired connection and provides the wired connection for all Mesh Points, which are the AP’s with no wired connection. In the IAP world, you cannot specify a dedicated Mesh Portal. A Mesh Point will always connect to the best Mesh Portal available, measured by signal strength.

To form a Mesh, all IAP’s has to be part of the same IAP cluster. This is important, as each cluster has its own VC Key. The IAP use this VC Key to identify the correct Mesh connection.

The first step is to create a PSK based SSID. I assume you know how to do this. Here is mine, just for testing:

wlan access-rule Aruba
 index 2
 rule any any match any any any permit

wlan ssid-profile Aruba
 enable
 index 0
 type employee
 essid Aruba
 wpa-passphrase 601d3a32a2a881f36c538b377bb4d37a225e65cdc35cf2ea
 opmode wpa2-psk-aes
 max-authentication-failures 0
 rf-band all
 captive-portal disable
 dtim-period 1
 broadcast-filter arp
 dmo-channel-utilization-threshold 90
 local-probe-req-thresh 0
 max-clients-threshold 64

Next step is to disable the extended SSID mode. Go to “System–>General” and enable the advanced mode (click the link at the bottom of the window “Show Advanced Options”) and disable the “Extended SSID” option:

InstantAP Mesh - Disable Extended SSID

InstantAP Mesh – Disable Extended SSID

You can also use the CLI:

# no extended-ssid 
# exit  
# commit apply 
committing configuration...
configuration committed.
# wr memory 
Save configuration.

You need to reboot all AP’s in the Cluster to disable the Extended SSID mode. Afterward, you can check the state of the extended SSID mode:

# show swarm state 

AP Swarm State           :swarm_config_sync_complete
mesh auto eth0 bridging  :no
Config in flash       :yes
factory SSID in flash :no
extended-ssid configured :no
extended-ssid active     :no
Factory default status   :no
Source of system time    :NTP server
Config load cnt       :1
VC Channel index      :1
IDS Client Gateway Detect :yes
Config Init success cnt for heartbeat   :0
Config Init success cnt for register    :0
Config Init skipping cnt for heartbeat  :0
Config Init skipping cnt for register   :0
Config Init last success reason   :N/A
Config Init last success time     :N/A

The AP’s are now ready to build a mesh. If one of the AP’s loose wired connectivity, the AP switches to mesh. This happens automatically but can take up to 15mins. The AP will reboot and during boot, you will see the following messages:

Ethernet uplink not active yet
Ethernet uplink not active yet
No uplink active. Becoming Mesh Point

The first 2 lines will repeat many times. After the last line, the AP will boot normally.

You can now check in the Web and CLI if the Mesh is up and running:

InstantAP Mesh - Running Mesh

InstantAP Mesh – Running Mesh

As you can see in the screenshot above, one AP is the Portal and one is the Point. You can get even more details from the CLI:

show ap mesh neighbours 

Neighbor list
-------------
MAC                Portal             Channel  Age  Hops  Cost  Relation                 Flags  RSSI  Rate Tx/Rx  A-Req  A-Resp  A-Fail  HT-Details        Cluster ID
---                ------             -------  ---  ----  ----  -----------------        -----  ----  ----------  -----  ------  ------  ----------        ----------
38:17:c3:09:92:51  80:8d:b7:10:77:b0  116E     0    1     1.00  C 41m:15s                VLK    35    650/390     4      4       0       VHT-80MHzsgi-2ss  bfb3420907204759d77aa4aa01e848a

Total count: 1, Children: 1
Relation: P = Parent; C = Child; N = Neighbor; B = Blacklisted-neighbor
Flags: R = Recovery-mode; S = Sub-threshold link; D = Reselection backoff; F = Auth-failure; H = High Throughput; V = Very High Throughput, L = Legacy allowed
        K = Connected; U = Upgrading; G = Descendant-upgrading; Z = Config pending; Y = Assoc-resp/Auth pending
        a = SAE Accepted; b = SAE Blacklisted-neighbour; e = SAE Enabled; u = portal-unreachable; o = opensystem

or this one:

show ap mesh link       

Neighbor list
-------------
MAC                Portal             Channel  Age  Hops  Cost  Relation                 Flags  RSSI  Rate Tx/Rx  A-Req  A-Resp  A-Fail  HT-Details        Cluster ID
---                ------             -------  ---  ----  ----  -----------------        -----  ----  ----------  -----  ------  ------  ----------        ----------
38:17:c3:09:92:51  80:8d:b7:10:77:b0  116E     0    1     1.00  C 41m:19s                VLK    35    702/390     4      4       0       VHT-80MHzsgi-2ss  bfb3420907204759d77aa4aa01e848a

Total count: 1, Children: 1
Relation: P = Parent; C = Child; N = Neighbor; B = Blacklisted-neighbor
Flags: R = Recovery-mode; S = Sub-threshold link; D = Reselection backoff; F = Auth-failure; H = High Throughput; V = Very High Throughput, L = Legacy allowed
        K = Connected; U = Upgrading; G = Descendant-upgrading; Z = Config pending; Y = Assoc-resp/Auth pending
        a = SAE Accepted; b = SAE Blacklisted-neighbour; e = SAE Enabled; u = portal-unreachable; o = opensystem

The AP will now use the Mesh link to connect to the Cluster and to send all the client traffic through this mesh link. In this mode, only wireless traffic is bridged through the Mesh link.

If the wired connection comes back, the AP will reboot again and use the wired link again.

InstantAP Mesh – Bridge Wired Traffic

In this scenario, we use the IAP Mesh to connect two networks with no wired connection between them, e.g. bridge over a street.

The same rules as above apply to this as well. So make sure the setup above is working. To enable the bridging from the ethernet port of the AP through the Mesh link enable “Eth bridging”. Click on the AP which should be the Point AP and click on “Edit”, go to “Uplink”:

InstantAP Mesh - Eth0 Bridging

InstantAP Mesh – Eth0 Bridging

You also need to make sure, that the port of the AP is aware of different VLAN’s. To configure the port accordingly, go to “More–>Wired” and create a new wired network:

InstantAP Mesh - Wired Settings

InstantAP Mesh – Wired Settings

Select “Employee” as “Primary usage” and click “Next”:

InstantAP Mesh - VLAN

InstantAP Mesh – VLAN

Select “Trunk” as “Mode” and define the “Native VLAN” and the “Allowed VLANs”. You can, of course, have more than one allowed VLAN. Afterward, click “Next”:

InstantAP Mesh - Security

InstantAP Mesh – Security

As the Mesh link bridges networks from our domain, we can trust all clients.

On the last tab, the “Access” tag, just click “Finish”.

You can now place the AP wherever you need the AP to interconnect two networks.

If the AP is up and running you can check the status in the CLI:

show ap mesh link 

Neighbor list
-------------
MAC                Portal             Channel  Age  Hops  Cost  Relation                 Flags  RSSI  Rate Tx/Rx  A-Req  A-Resp  A-Fail  HT-Details        Cluster ID
---                ------             -------  ---  ----  ----  -----------------        -----  ----  ----------  -----  ------  ------  ----------        ----------
38:17:c3:09:92:51  80:8d:b7:10:77:b0  116E     0    1     1.00  C 17m:50s                VLK    32    325/325     4      4       0       VHT-80MHzsgi-2ss  bfb3420907204759d77aa4aa01e848a

Total count: 1, Children: 1
Relation: P = Parent; C = Child; N = Neighbor; B = Blacklisted-neighbor
Flags: R = Recovery-mode; S = Sub-threshold link; D = Reselection backoff; F = Auth-failure; H = High Throughput; V = Very High Throughput, L = Legacy allowed
        K = Connected; U = Upgrading; G = Descendant-upgrading; Z = Config pending; Y = Assoc-resp/Auth pending
        a = SAE Accepted; b = SAE Blacklisted-neighbour; e = SAE Enabled; u = portal-unreachable; o = opensystem

Clients behind the AP are now bridged through the Mesh link as well.

What is your main goal to build a mesh? Interconnect networks or connect AP’s with no wired connection?

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post Aruba InstantAP Mesh – IAP Mesh appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/08/aruba-instantap-mesh-iap-mesh/feed/ 0 1114
Aruba Instant VPN with Central – IAP VPN https://www.flomain.de/2018/07/aruba-instant-vpn-with-central-iap-vpn/ https://www.flomain.de/2018/07/aruba-instant-vpn-with-central-iap-vpn/#respond Wed, 04 Jul 2018 11:30:15 +0000 https://www.flomain.de/?p=1029 In this post, I describe how I use an Aruba Instant AP for tunnel all my traffic to my controller at home. This IAP VPN is very helpful when I need to show some lab scenarios. But you can also use it as your secure connection from a small branch office to the headquarter. Sure, you […]

The post Aruba Instant VPN with Central – IAP VPN appeared first on Flomain Networking.

]]>
In this post, I describe how I use an Aruba Instant AP for tunnel all my traffic to my controller at home. This IAP VPN is very helpful when I need to show some lab scenarios. But you can also use it as your secure connection from a small branch office to the headquarter. Sure, you could use a RAP (Remote AP) and I used this setup in the past very successful, but the IAP solution scales much better.

You can have just a limited number of RAP’s in one location. But you can have up to 128 IAP’s per location. Whenever you need more than 4 RAP’s, consider the IAP VPN solution as well.

In the setup below, I use central for management. But you can also use AirWave or no management and configure the IAP’s manually, as well, to get the same results.

IAP VPN – Basic Setup

Normally, you send the wireless user in an IAP solution in a VLAN. But sometimes you need a central breakout for the users. This is possible with the IAP VPN solution. All you need is a controller, or for redundancy two controllers, at the central breakout point. The IAP create an IPSec tunnel to this controller. You can use this tunnel to send user traffic to the controller. The controller can now handle the traffic and send it to a VLAN at the central site.

The setup is very simple and easy. I start with the controller part. and afterward with the IAP part in central.

I run ArubaOS 8 on the controller:

show version

Aruba Operating System Software.
ArubaOS (MODEL: Aruba7005), Version 8.2.1.0
Website: http://www.arubanetworks.com
(c) Copyright 2018 Hewlett Packard Enterprise Development LP.
Compiled on 2018-03-16 at 17:27:35 UTC (build 64044) by p4build

ROM: System Bootstrap, Version CPBoot 1.0.2.0 (build 46859)
Built: 2014-10-31 10:10:57
Built by: p4build@re_client_46859


Switch uptime is 4 days 4 hours 21 minutes 8 seconds
Reboot Cause: POE Power Cycle (Intent:cause:register ee:ee:0:c)
Supervisor Card
Processor (XLP208 Rev B0 (Secure Boot) , 500 MHz) with 3797M bytes of memory.
32K bytes of non-volatile configuration memory.
1920M bytes of Supervisor Card system flash.

The first step is to allow the IAP on the controller. This is the same as with all other AP’s. You need to whitelist the IAP. I use whitelist auth with ClearPass. Here you can check, how to use ClearPass for whitelist sync:

ArubaOS Controller Whitelist Sync with ClearPass

You have to use the remote AP whitelist for the IAP’s. And If you use ClearPass or any other radius server you can also psecify the role for the IAP. Below is the summary screen of my enforcement profile for any IAP authentication:

IAP VPN - Enforcement Profile in ClearPass

IAP VPN – Enforcement Profile in ClearPass

I use the default group, for the group assignment. You can use a different one, but keep in mind, the group doesn’t madders in this setup, as the controller did not apply any configuration for the IAP. Important is the “Aruba-Location-Id” to assign the correct IAP name on the controller. This makes troubleshooting much easier, later on. The role is not needed, as the controller has a default role for the IAP’s. If you would like to change it, you can send the role attribute as well.

The last step on the controller is to create an IP pool, for the inner tunnel IP’s. Either use the CLI and use this command:

ip local pool "mobile-iap" 10.193.168.2 10.193.168.254

Or you can do the same in the GUI. Go to “Configuration–>Services–>VPN” and go down to “General VPN”. To create a new “Address Pool”, click the “+” sign:

IAP VPN - Create IP Address Pool

IAP VPN – Create IP Address Pool

From this “Address Pool”, the IAP gets an inner tunnel IP address. You can either create a NAT rule for this address range or, which is my recommendation, use OSPF to distribute the routes in your environment. If you need help with OSPF on the Aruba controller, leave me a comment and I will help you, or write a post about it.

That is the controller part.

IAP VPN – IAP Part

I will show the setup with Aruba Central, but the configuration is the same for AirWave or the Instant GUI.

To start the configuration go to “Wireless Management–>VPN”:

IAP VPN - Configure Aruba IPSec in Central

IAP VPN – Configure Aruba IPSec in Central

Replace the “Primary Host” and the “Backup Host” with your hostnames or IP addresses and make sure, you select “Aruba IPsec as the “Protocol”.

This creates a tunnel from the virtual controller of the IAP cluster to the Aruba controller. You can also select “Aruba GRE” for the “Protocol”. With “Aruba GRE”, you can build tunnels from every IAP in the cluster to the controller. This is very handy when you cannot use VLAN Tags between the IAP’s. The configuration would look like this:

IAP-VPN - Configure Aruba GRE in Central

IAP-VPN – Configure Aruba GRE in Central

This creates a VPN tunnel from every IAP to the controller. This makes sense when you are not able to work with VLAN tags between the IAP cluster notes.

You can also configure “L2TPv3” and “Manual GRE”. But I have never used them in the past.

To allow the IAP, to reach internal resources as well, you can configure “Routing”. This is just below the configuration from above:

IAP VPN - Configure Routing Profile in Central

IAP VPN – Configure Routing Profile in Central

You can configure hosts or subnets to be available behind the tunnel. The important part is, that you need to configure the controller IP (the one, the IAP is connected to) as the gateway.

IAP VPN – Show Commands

You can check if the VPN is up and running from the CLI. First, let’s check the controller part. There is an ISAKMP entry for the IAP:

(wlan-controller) #show crypto isakmp sa 

ISAKMP SA Active Session Information
------------------------------------
Initiator IP                              Responder IP                              Flags       Start Time      Private IP     
------------                              ------------                              -----     ---------------   ----------     
10.100.100.50                             10.100.100.70                             i-v2-p    Jul  3 02:19:33     -                                       
10.106.106.10                             10.100.100.50                             r-v2-c-C  Jul  3 04:37:59   10.106.106.10                             
10.106.106.11                             10.100.100.50                             r-v2-c-C  Jul  3 04:53:29   10.106.106.11                             
137.226.133.33                            10.100.100.50                             r-v2-c-I  Jul  3 09:58:35   10.99.99.10                               

Flags: i = Initiator; r = Responder
       m = Main Mode; a = Agressive Mode; v2 = IKEv2
       p = Pre-shared key; c = Certificate/RSA Signature; e =  ECDSA Signature
       x = XAuth Enabled; y = Mode-Config Enabled; E = EAP Enabled
       3 = 3rd party AP; C = Campus AP; R = RAP;  Ru = Custom Certificate RAP; I = IAP
       V = VIA; S = VIA over TCP

Total ISAKMP SAs: 4

The last entry is the IAP. It is the VC. I use the Aruba IPSec option for the VPN. There is also an IPSec SA entry:

(wlan-controller) #show crypto ipsec sa 

 
IPSEC SA (V2) Active Session Information
-----------------------------------
Initiator IP                              Responder IP                              SPI(IN/OUT)        Flags Start Time        Inner IP
------------                              ------------                              ----------------   ----- ---------------   --------
137.226.133.33                            10.100.100.50                             ae840700/47eaac00  UT2   Jul  3 09:58:34   10.99.99.10                               
10.100.100.50                             10.100.100.70                             9ed8e900/f4c43400  UT2   Jul  3 09:53:35     -                                       
10.106.106.11                             10.100.100.50                             81b8a900/fa64ed00  UT2   Jul  3 08:34:58   10.106.106.11                             
10.106.106.10                             10.100.100.50                             756f1b00/20537e00  UT2   Jul  3 09:50:45   10.106.106.10                             

Flags: T = Tunnel Mode; E = Transport Mode; U = UDP Encap
       L = L2TP Tunnel; N = Nortel Client; C = Client; 2 = IKEv2

Total IPSEC SAs: 4

This time, it is the first entry. If both entries are present, you have the IAP in the IAP table as well:

(wlan-controller) #show iap table long 

Trusted Branch Validation: Enabled
IAP Branch Table
----------------
Name         VC MAC Address     Status  Inner IP     Assigned Subnet  Assigned Vlan  Key                                                 Bid(Subnet Name)  Tunnel End Points
----         --------------     ------  --------     ---------------  -------------  ---                                                 ----------------  -----------------
ELAB-VC-001  b4:5d:50:c1:ef:fc  UP      10.99.99.10                                  d80c02fb01ab73336419c72095819606e430511260f2fecfa4                    

Total No of UP Branches   : 1
Total No of DOWN Branches : 0
Total No of Branches      : 1

Now, from the IAP:

ELAB-AP-003# show vpn status 


profile name:default
--------------------------------------------------
current using tunnel                            :primary tunnel
current tunnel using time                       :8 minutes 57 seconds 
ipsec is preempt status                         :disable
ipsec is fast failover status                   :disable
ipsec hold on period                            :600s
ipsec tunnel monitor frequency (seconds/packet) :5
ipsec tunnel monitor timeout by lost packet cnt :6

ipsec     primary tunnel crypto type            :Cert
ipsec     primary tunnel peer address           :controller-fqdn.tld
ipsec     primary tunnel peer tunnel ip         :10.100.100.50
ipsec     primary tunnel ap tunnel ip           :10.99.99.10
ipsec     primary tunnel using interface        :tun0
ipsec     primary tunnel using MTU              :1230
ipsec     primary tunnel current sm status      :Up
ipsec     primary tunnel tunnel status          :Up
ipsec     primary tunnel tunnel retry times     :1
ipsec     primary tunnel tunnel uptime          :8 minutes 57 seconds 

ipsec      backup tunnel crypto type            :Cert
ipsec      backup tunnel peer address           :N/A
ipsec      backup tunnel peer tunnel ip         :N/A
ipsec      backup tunnel ap tunnel ip           :N/A
ipsec      backup tunnel using interface        :N/A
ipsec      backup tunnel using MTU              :N/A
ipsec      backup tunnel current sm status      :Init
ipsec      backup tunnel tunnel status          :Down
ipsec      backup tunnel tunnel retry times     :0
ipsec      backup tunnel tunnel uptime          :0

From the output above, you can see, that the primary tunnel is up.

ELAB-AP-003# show vpn tunnels 

Tunnel Flags: M = Master IAP; S = Slave IAP; P = Primary Tunnel
              B = Backup Tunnel; R = Registered; H = Heartbeat Enable

Tunnel Info for peer address  10.100.100.50
--------------------------------------------
Type                               Value
----                               -----
Source IP                          10.99.99.10
Destination IP                     10.100.100.50
End IP                             84.153.110.129
Default GW                         192.168.0.254
Use count                          1
Ifindex                            17
Ifname                             tun0
Flags                              MPRH
Retry count for Register Request   0
Last Heartbeat                     15998
Heartbeat Encap/Decap              108(seq 108)/109(seq 108)
GRE Encap/Decap                    1582/1581
For DHCP Profile                   ELAB-Management
 Retry count for Vlan Add Request  0
 Old Subnet Status                 Normal
 Existing Subnet Status            Normal

On a slave IAP it looks like this:

ELAB-AP-001# show vpn status


profile name:default
--------------------------------------------------
current using tunnel                            :unselected tunnel
current tunnel using time                       :0
ipsec is preempt status                         :disable
ipsec is fast failover status                   :disable
ipsec hold on period                            :600s
ipsec tunnel monitor frequency (seconds/packet) :5
ipsec tunnel monitor timeout by lost packet cnt :6

ipsec     primary tunnel crypto type            :Cert
ipsec     primary tunnel peer address           :N/A
ipsec     primary tunnel peer tunnel ip         :N/A
ipsec     primary tunnel ap tunnel ip           :N/A
ipsec     primary tunnel using interface        :N/A
ipsec     primary tunnel using MTU              :N/A
ipsec     primary tunnel current sm status      :Init
ipsec     primary tunnel tunnel status          :Down
ipsec     primary tunnel tunnel retry times     :0
ipsec     primary tunnel tunnel uptime          :0

ipsec      backup tunnel crypto type            :Cert
ipsec      backup tunnel peer address           :N/A
ipsec      backup tunnel peer tunnel ip         :N/A
ipsec      backup tunnel ap tunnel ip           :N/A
ipsec      backup tunnel using interface        :N/A
ipsec      backup tunnel using MTU              :N/A
ipsec      backup tunnel current sm status      :Init
ipsec      backup tunnel tunnel status          :Down
ipsec      backup tunnel tunnel retry times     :0
ipsec      backup tunnel tunnel uptime          :0
ELAB-AP-001# show vpn tunnels 

Tunnel Flags: M = Master IAP; S = Slave IAP; P = Primary Tunnel
              B = Backup Tunnel; R = Registered; H = Heartbeat Enable

Tunnel Info for peer address  10.100.100.50
--------------------------------------------
Type                               Value
----                               -----
Source IP                          10.99.99.10
Destination IP                     10.100.100.50
End IP                             84.153.110.129
Default GW                         0.0.0.0
Use count                          0
Ifindex                            0
Ifname                             Null
Flags                              SP
Retry count for Register Request   0
GRE Encap/Decap                    0/0
For DHCP Profile                   ELAB-Management
 Retry count for Vlan Add Request  0
 Old Subnet Status                 Normal
 Existing Subnet Status            Normal

Now, let’s change the VPN type to Aruba GRE. I also enable “Per -AP-Tunnel”.

The first two commands look the same. There is one IPSec tunnel from the VC to the controller. But the last output from the controller is different:

(wlan-controller) #show iap table long 

Trusted Branch Validation: Enabled
IAP Branch Table
----------------
Name         VC MAC Address     Status  Inner IP     Assigned Subnet  Assigned Vlan  Key                                                 Bid(Subnet Name)  Tunnel End Points
----         --------------     ------  --------     ---------------  -------------  ---                                                 ----------------  -----------------
ELAB-VC-001  b4:5d:50:c1:ef:fc  UP      10.99.99.10                                  d80c02fb01ab73336419c72095819606e430511260f2fecfa4                    192.168.0.180,192.168.0.183,192.168.0.182,192.168.0.181 

Total No of UP Branches   : 1
Total No of DOWN Branches : 0
Total No of Branches      : 1

As you see from the output above, the controller list all the IAP’s in the IAP cluster as well.

The IAP output is different as well. The VC has one IPSec tunnel active:

ELAB-AP-003# show vpn status 


profile name:default
--------------------------------------------------
current using tunnel                            :primary tunnel
current tunnel using time                       :17 minutes 39 seconds 
ipsec is preempt status                         :disable
ipsec is fast failover status                   :disable
ipsec hold on period                            :600s
ipsec tunnel monitor frequency (seconds/packet) :5
ipsec tunnel monitor timeout by lost packet cnt :6

ipsec     primary tunnel crypto type            :Cert
ipsec     primary tunnel peer address           :controller-fqdn.tld
ipsec     primary tunnel peer tunnel ip         :10.100.100.50
ipsec     primary tunnel ap tunnel ip           :10.99.99.10
ipsec     primary tunnel using interface        :tun0
ipsec     primary tunnel using MTU              :1230
ipsec     primary tunnel current sm status      :Up
ipsec     primary tunnel tunnel status          :Up
ipsec     primary tunnel tunnel retry times     :1
ipsec     primary tunnel tunnel uptime          :17 minutes 39 seconds 

ipsec      backup tunnel crypto type            :Cert
ipsec      backup tunnel peer address           :N/A
ipsec      backup tunnel peer tunnel ip         :N/A
ipsec      backup tunnel ap tunnel ip           :N/A
ipsec      backup tunnel using interface        :N/A
ipsec      backup tunnel using MTU              :N/A
ipsec      backup tunnel current sm status      :Init
ipsec      backup tunnel tunnel status          :Down
ipsec      backup tunnel tunnel retry times     :0
ipsec      backup tunnel tunnel uptime          :0

And through the IPSec tunnel, the IAP has a GRE tunnel:

ELAB-AP-003# show vpn tunnels 

Tunnel Flags: M = Master IAP; S = Slave IAP; P = Primary Tunnel
              B = Backup Tunnel; R = Registered; H = Heartbeat Enable

Tunnel Info for peer address  10.100.100.50
--------------------------------------------
Type                               Value
----                               -----
Source IP                          10.99.99.10
Destination IP                     10.100.100.50
End IP                             84.153.110.129
Default GW                         192.168.0.254
Use count                          1
Ifindex                            17
Ifname                             tun0
Flags                              MPRH
Retry count for Register Request   0
Last Heartbeat                     15529
Heartbeat Encap/Decap              496(seq 496)/496(seq 496)
GRE Encap/Decap                    1114/1113
For DHCP Profile                   ELAB-Management
 Retry count for Vlan Add Request  0
 Old Subnet Status                 Normal
 Existing Subnet Status            Normal

From a slave IAP it looks like this:

ELAB-AP-001# show vpn status


profile name:default
--------------------------------------------------
current using tunnel                            :unselected tunnel
current tunnel using time                       :0
ipsec is preempt status                         :disable
ipsec is fast failover status                   :disable
ipsec hold on period                            :600s
ipsec tunnel monitor frequency (seconds/packet) :5
ipsec tunnel monitor timeout by lost packet cnt :6

ipsec     primary tunnel crypto type            :Cert
ipsec     primary tunnel peer address           :N/A
ipsec     primary tunnel peer tunnel ip         :N/A
ipsec     primary tunnel ap tunnel ip           :N/A
ipsec     primary tunnel using interface        :N/A
ipsec     primary tunnel using MTU              :N/A
ipsec     primary tunnel current sm status      :Init
ipsec     primary tunnel tunnel status          :Down
ipsec     primary tunnel tunnel retry times     :0
ipsec     primary tunnel tunnel uptime          :0

ipsec      backup tunnel crypto type            :Cert
ipsec      backup tunnel peer address           :N/A
ipsec      backup tunnel peer tunnel ip         :N/A
ipsec      backup tunnel ap tunnel ip           :N/A
ipsec      backup tunnel using interface        :N/A
ipsec      backup tunnel using MTU              :N/A
ipsec      backup tunnel current sm status      :Init
ipsec      backup tunnel tunnel status          :Down
ipsec      backup tunnel tunnel retry times     :0
ipsec      backup tunnel tunnel uptime          :0
ELAB-AP-001# show vpn tunnels

Tunnel Flags: M = Master IAP; S = Slave IAP; P = Primary Tunnel
              B = Backup Tunnel; R = Registered; H = Heartbeat Enable

Tunnel Info for peer address  10.100.100.50
--------------------------------------------
Type                               Value
----                               -----
Source IP                          10.99.99.10
Destination IP                     10.100.100.50
End IP                             84.153.110.129
Default GW                         0.0.0.0
Use count                          0
Ifindex                            0
Ifname                             Null
Flags                              SP
Retry count for Register Request   0
GRE Encap/Decap                    0/0
For DHCP Profile                   ELAB-Management
 Retry count for Vlan Add Request  0
 Old Subnet Status                 Normal
 Existing Subnet Status            Normal

There is no VPN active. But there is a GRE tunnel (the lower output). This GRE tunnel uses the IPSec tunnel from the VC as well. This allows the GRE tunnel to work even in an environment with NAT devices between the IAP and the controller. Isn’t this a great feature?

You have now the connection between the IAP and the central controller. All the different options, to use this connection will come in one of the next posts.

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post Aruba Instant VPN with Central – IAP VPN appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/07/aruba-instant-vpn-with-central-iap-vpn/feed/ 0 1029
ArubaOS Controller Whitelist Sync with ClearPass https://www.flomain.de/2018/04/arubaos-controller-whitelist-sync-with-clearpass/ https://www.flomain.de/2018/04/arubaos-controller-whitelist-sync-with-clearpass/#comments Wed, 18 Apr 2018 16:52:52 +0000 https://www.flomain.de/?p=1032 I was writing some new posts and realized that I missed one basic post for you. If you ever went through the process of provisioning many new AP’s to a controller, you may be looked for a simpler way to do the provisioning work. The solution is the whitelist. Every ArubaOS controller has an internal whitelist […]

The post ArubaOS Controller Whitelist Sync with ClearPass appeared first on Flomain Networking.

]]>
I was writing some new posts and realized that I missed one basic post for you. If you ever went through the process of provisioning many new AP’s to a controller, you may be looked for a simpler way to do the provisioning work. The solution is the whitelist. Every ArubaOS controller has an internal whitelist for campus AP’s and remote AP’s.

This whitelist has an entry for every AP (CAP, RAP and even IAP) and you can use the whitelist together with CPSec. I will not talk about CPSec in this post, but my recommendation is to enable CPSec in every deployment. It is best to enable it during initial configuration. But you can also enable it later, but be aware, that this can cause a service interruption during the migration phase to CPSec. Speak to your local partner or Aruba peers to plan the migration.

What is the Whitelist

The whitelist maintains a list of all trusted AP’s. You can also revoke the trust. This is great if AP’s get lost and you would like to deny access to those AP’s. But the whitelist ist even more. The whitelist contains the AP name and the group. And here is the main benefit from my point of view. You can define AP name and group before the AP joins your network. If the AP connects, the AP gets the name and group from the whitelist and the manual provision part is removed.

How to Fill the Whitelist Manually

The whitelist is just a database on the controller. You can manually add, remove or modify entries. To add an entry, go to “Configuration–>Access Points–>Whitelist” and select either the “Campus AP Whitelist” or the “Remote AP Whitelist”. I think the names speak for themselves. IAP’s are part of the “Remote AP Whitelist”. To add a new entry, simply click the “+” sign at the bottom:

Add Device to Whitelist

Add Device to Whitelist

You can do the same on the CLI:

(MM) *[Haan-Live] (config) #whitelist-db cpsec add mac-address ff:0b:86:68:2e:12 ap-group WLAN-Haan ap-name Test-AP description "Test AP for Whitelist"

This creates an entry in the whitelist. If the AP with the specified mac address connects to the controller, the AP is automatically provisioned with the AP name and AP group from the whitelist.

To change the AP name or the group, you simply modify the whitelist entry. In the GUI, simply click on the AP entry and change the parameters:

Modify Device in the Whitelist

Modify Device in the Whitelist

You can “Revoke” or “Delete” the AP from this screen as well. My recommendation is to revoke the AP, instead of deleting the AP, if you would like to deny access for this AP. This creates a defined state for the AP.

You can do the same in the CLI:

(MM) *[Haan-Live] (config) #whitelist-db cpsec modify mac-address ff:0b:86:68:2e:12 ap-group default ap-name Test-AP-Modified
     cert-type Certificate type
     description Description
     mode Revoke/Unrevoke entry
     revoke-text Revoke-text
     state Whitelist DB entry state

The benefit of the CLI, you can change even more options. I will not get into the details as most of the options are advanced options and you should not change them without consultation with your partner or Aruba peer.

The last option is to remove an AP.

To delete the AP from the whitelist, just click the delete button. This is not very special. The CLI command looks like this:

whitelist-db cpsec del mac-address ff:0b:86:68:2e:12

This is the manual way to whitelist AP’s. There is a semi-automatically way as well.

How to Offload the Whitelist to ClearPass – Controller Part

You can also offload the whitelist to ClearPass. This is my preferred method. This workflow is very easy. The AP connects to the controller and the controller uses MAC authentication against a radius server. The radius server needs to know about the AP. Upon successful authentication, the AP can connect to the controller.

From my point of view, this is the best method, as you can change the parameters for the AP, like name and group on the radius server or in your database, where the AP information is saved.

My recommendation is to use some kind of asset database for this. For my lab, I use my Active Directory. So, all my AP’s are accounts in my AD database and I use ClearPass to query them. But let’s start at the beginning.

To offload the whitelist to ClearPass, you need to add ClearPass as an authentication server to the controller. Go to “Authentication–>Auth Servers” and click the “+” sign in the “All Servers” box:

Add Auth Server for Whitelist Sync

Add Auth Server for Whitelist Sync

Select the “Add new server” radio button and specify a name. Choose either the hostname or the IP of your radius server. Leave the “Type” as “Radius” and click submit. The new server is now on the list of “All Servers”. Select the created server and configure the required details:

Add Auth Server Details for Whitelist Sync

Add Auth Server Details for Whitelist Sync

I have most of the options with the default value. The main important one is the “Shared key”. This key should be the same, on the controller and on ClearPass. Below is the CLI command, to create the server:

show configuration effective wlan-controller | begin authentication-server
aaa authentication-server radius "CPPM-Haan"
    host "cppm.flomain.local"
    key 536ad24d815828bd145043bebdf430451b756f43ef4cf619
    nas-identifier "10.100.100.50"
    nas-ip 10.100.100.50

This is a good example of the hierarchical configuration of ArubaOS 8. The screenshot above is from the group level and the CLI part is from the controller. In the GUI at the group level, you configure just the main parameters and you add controller specific settings like the “nas-ip” or the “nas-identifier” on the controller level. To get the output with the same content as the screenshot above, check the config in the group level from the CLI:

show configuration effective /md/haan-Live | begin authentication-server
aaa authentication-server radius "CPPM-Haan"
    host "cppm.flomain.local"
    key 453be891e6ff5de1798b950bed505b31f48b445f7f3b2dbc

This was just a side note, as this example shows very well how the hierarchical configuration model can work in ArubaOS 8.

The last step is to add the server to a radius group. Go to “Authentication–>Auth Servers” and click the “+” sign in the “Server Groups” box, if you have no server group. Just enter the name of the server group and click “Submit”. Afterward, select the server group and click the “+” sign in the “Server Group” box, to add an existing server to the group. Simply click “Submit” afterward. The configuration looks like this:

show configuration effective wlan-controller | begin "aaa server-group"
aaa server-group "CPPM"
 auth-server CPPM-Haan position 1
 auth-server CPPM-Haan trim-fqdn position 1

I remove the domain portion of the username as well with the last configuration line. This is not needed for the whitelist sync, but I use this radius server group for other authentication stuff as well.

The last step is to tell the controller, to use ClearPass for any Campus AP authentication. Go to “Authentication–>L3 Authentication” and go through the L3 Authentication tree to “VPN Authentication–>default-cap–>Server Group” and change the “Server Group” to the one, you have created above:

Change Server Group for Whitelist Authentication

Change Server Group for Whitelist Authentication

From the CLI it looks like this:

show configuration effective /md/haan-Live | begin default-cap

aaa authentication vpn “default-cap”
default-role “sys-ap-role”
server-group “CPPM”
!

Afterward, the controller uses ClearPass to authenticate every AP, which is trying to connect to the controller. To get the same for RAP’s and IAP’s, just change the “Server Group” for the “default-rap” and “default-iap” profile as well.

How to Offload the Whitelist to ClearPass – ClearPass Part

This part is easy as well. But let’s start from the beginning. First, you create the “Enforcement Profile”. This includes the parameter for the AP name and group. Login to ClearPass and go to “Configuration–>Enforcement–>Profiles” and create a new profile of the type “Radius”:

Create Enforcement Profile

Create Enforcement Profile

The most important part is in the “Attributes” section. I have two attributes, the “Aruba-AP-Group” and the “Aruba-Location-Id”. The first one is the AP group. Make sure, this one matches one of the AP groups on the controller. The second one is the AP name. Even if the name of the attribute is not emphasizing this.

The next step is to create the “Enforcement Policy”, but before you need to know my “Role-Mapping”:

Role Mapping

Role Mapping

The screenshot above shows my role mapping. I use different Active Directory groups to assign roles to different users and devices. This is not necessary, but I find it very convenient because you can use these roles in the “Enforcement Policy”. And that is the reason for the sides step to the role mapping. Without this screenshot, you would not understand my “Enforcement Policy”.

To create a new “Enforcement Policy”, go to “Configuration–>Enforcement–>Policies” and add a new “Enforcement Policy” with the click of the “+ Add” link in the right upper corner. Make sure, it is a “Radius” type policy. The summary of my policy looks like this:

Enforcement Profile

Enforcement Profile

As you see, I use the roles from the mapping above to define the action. And the action is an “Enforcement Profile”  In the case of condition 2, it is the profile from above. My lab environment is very simple, so no complicated conditions. Your conditions could look totally different, depending on your environment.

The last and final step is to create a service, which uses the role mapping and the “Enforcement Policy” to bring all together. To create a new service in ClearPass, go to “Configuration–>Services” and click the “+ Add” link. My service looks like this:

Whitelist Service in ClearPass

Whitelist Service in ClearPass

This is just the summary screen but is showing all important parameters. The “Service Rule”s are there to classify the request and route the request to this service. Make sure, it does not interfere with other services.

I have all the default “Authentication Methods” from the “802.1x Wireless” template, plus the “MAC_AUTH” method. This one is the only one, which is important. I use my AD as the “Authentication Source”. You also find my role mapping from above and the “Enforcement Profile”.

That was the ClearPass part and you can connect your AP’s.

Dynamically Adjust Whitelist with ClearPass

After all the above is configured, you can start to connect AP’s. I have connected one AP and this is the output from the controller after the AP is up and running:

(wlan-controller) #show ap database
AP Database
-----------
Name           Group      AP Type  IP Address     Status     Flags  Switch IP      Standby IP
----           -----      -------  ----------     ------     -----  ---------      ----------
AP-Wohnzimmer  WLAN-Haan  225      10.200.200.12  Up 31m:7s  2      10.100.100.50  0.0.0.0

The AP is in the group “WLAN-Haan” and has the name “AP-Wohnzimmer”. From ClearPass, it looks like this:

Output Details from ClearPass

Output Details from ClearPass

As you can see, the AP name and group from above matches the radius response in ClearPass. I will now change the name of the AP in my directory to “AP-Wohnzimmer-Test”. Let’s see what happens after I reboot the AP. First the output from ClearPass:

Output Details from ClearPass with new AP Name

Output Details from ClearPass with new AP Name

As you see, the name changed to “AP-Wohnzimmer-Test”. Now, let’s check if the controller has applied this as well:

(wlan-controller) #show ap database
AP Database
-----------
Name                Group      AP Type  IP Address     Status     Flags  Switch IP      Standby IP
----                -----      -------  ----------     ------     -----  ---------      ----------
AP-Wohnzimmer-Test  WLAN-Haan  225      10.200.200.12  Up 4m:43s  2      10.100.100.50  0.0.0.0

The AP name is changed on the controller. With the same steps, you can change the AP group as well.  This makes it very easy to manage large lists of AP’s in a directory.

If you change the AP group, the AP reboots twice. The first one is initiated by the user to assign the new group and the second one is initiated by the AP to apply the new group configuration.

Offload the Whitelist to Aruba Activate

For RAP’s and IAP’s, you still need to convert them (for RAP’s) and point them to the controller. For this task, you can use Aruba Activate. This cloud tool can do this automatically for you. The RAP/IAP needs internet access, but this is the main requirement for all cloud-based tools.

If you have all the RAP’s/IAP’s already in Activate, it would make no sense to maintain them in a local database as well. And here comes the cool stuff. You can use Activate as well, to fill your whitelist. Make sure, the AP’s are in Activate and the rules are applied as well. I will not show this in this post, but if you need help with Activate, post your questions in the comment section below this article and I will help you.

On the mobility master, configure Activate in your hierarchy level of choice, to enable Activate sync on the managed devices. You only need to add Activate and your credentials to the configuration:

(MM) ^*[Haan-Live] (activate) #
add-only                Allow only addition of entries to whitelist DB
ca-cert                 Custom cert to upload to Activate
device-interval         Periodic interval for Device WhiteList Sync (in Hours)
device-whitelist-enable Enable or disable Activate Device Whitelist Service
interval                Periodic interval for AP WhiteList Sync (in days)
no                      Delete Command
password                Password Credential for Activate Login
provisionurl            Provision Activate URL
server-cert             Server cert to be used for IPSEC
url                     Activate URL
username                Username Credential for Activate Login
whitelist-enable        Enable or disable Activate AP Whitelist Service

The most important configuration steps are the following:

(MM) ^*[Haan-Live] (activate) #add-only

I use this is one most of the time. This will only add devices from Activate. But if they disappear from Activate, they will stay in the whitelist.

(MM) ^*[Haan-Live] (activate) #password ***********

This one is the Activate password and below is the command for the username:

(MM) ^*[Haan-Live] (activate) #username your_activate_account@your_compony.tld

The last and most important command is to enable the service:

(MM) ^*[Haan-Live] (activate) #whitelist-enable

To force the download you use this command on the managed device:

(wlan-controller) #activate whitelist download

Afterward, you should have all RAP’s and IAP’s in the remote whitelist. This makes it very easy to manage the whitelist without to much work on your side. The controller contacts Activate on a regular basis to update the list.

How do you manage your whitelist during rollout and operations? Leave me a comment so that I get a better feeling what other people are doing.

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post ArubaOS Controller Whitelist Sync with ClearPass appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/04/arubaos-controller-whitelist-sync-with-clearpass/feed/ 1 1032
AirWave RestAPI with PowerShell https://www.flomain.de/2018/02/airwave-restapi/ https://www.flomain.de/2018/02/airwave-restapi/#respond Wed, 21 Feb 2018 12:30:05 +0000 https://www.flomain.de/?p=1018 In some of my latest projects, I used the AirWave RestAPI. The main purpose was to either extend the functionality of AirWave or to automate some workflows. In this post, I show, how to interact with the AirWave RestAPI. AirWave RestAPI: Yes, AirWave has an API AirWave is a great tool to manage your wireless and […]

The post AirWave RestAPI with PowerShell appeared first on Flomain Networking.

]]>
In some of my latest projects, I used the AirWave RestAPI. The main purpose was to either extend the functionality of AirWave or to automate some workflows. In this post, I show, how to interact with the AirWave RestAPI.

AirWave RestAPI: Yes, AirWave has an API

AirWave is a great tool to manage your wireless and wired infrastructure. And like all other products from Aruba, it as an API as well. You can use a RestAPI to communicate with AirWave. I agree, this API is not the most powerful one and is leaking some functions. Especially, when it comes to adding and removing devices. But I’m pretty sure, that some smart guys already working on this.

You can get access to the API from your AirWave system. Login to AirWave and go to “Home–>Documentation”:

AirWave RestAPI - Documentation

AirWave RestAPI – Documentation

The section in the blue frame has the RestAPI documentation. I have some experience with the “State and Statistical XML API”. You can find the documentation and examples after you click the “HTML” link.

AirWave RestAPI uses XML to transfer information. The input is URL encoded. This makes the AirWave RestAPI very simple and easy to use.

AirWave RestAPI: How to Use the RestAPI

You can use the AirWave RestAPI with every language, who supports HTTP requests. For the example below, I use PowerShell. Just because I wanted to learn PowerShell.

Before you can read or write data with the RestAPI you need to log in. Unfortunately, the authentication is not described in the documentation. The reason might be, that it is not rocket science for those who do programming all day long. For me, it was the hardest part.

You use the default login page to create a session. Specifically, the HTTP Post request, from the login page. In PowerShell, it looks like this:

#Create the Login URL
$loginUri = "https://" + $airwavehost + "/LOGIN"
#Create the username password combination
$body = "credential_0=" + $username + "&credential_1=" + $password + "&destination=/index.html"

#Login to AirWave and save the session into the session variable
$loginObj = Invoke-RestMethod -Uri $loginUri -Method Post -Body $body -ContentType 'application/x-www-form-urlencoded;charset=UTF-8' -SessionVariable session

Just convert this into an undersandable language.

First I create the URL for the login request. This looks like this:

https://airwave.flomain.local/LOGIN

Now, I create the username/password combination and the destination after a successful login. I send this to the URL from above. The data look like this:

credentials_0=admin&credentials_1=admin&destiantion=/index.html

This still looks very cryptic. Forget about the “destination” variable. The important one is “credentials_0” and “credentials_1”. The first one is the username and the second one is the password.

Put all together in a request like this:

$loginObj = Invoke-RestMethod -Uri $loginUri -Method Post -Body $body -ContentType 'application/x-www-form-urlencoded;charset=UTF-8' -SessionVariable session

This creates an HTTP Post to the URL from above. It uses the data with the credentials to log in and it creates a session. I save this session in the “session” variable. If the login is successful you can use the “session” variable for all other requests without any login.

AirWave RestAPI: A Simple Script

To play around with the API, my goal was to extract some data from AirWave. I always play with AirWave in my lab and brake something. So I do a fresh installation. No time for backups, for this kind of play and destroy systems. After the installation, I need to add all the devices from my lab to AirWave, again.

My idea is, to have a script, which can extract all or some devices in a format which I can use to reimport into a new AirWave installation. Sure, I could create this file by hand, but I wanted to play with PowerShell and the RestAPI. and the script is really simple. It took me only half a day to write the script. Most of the time I spend figuring out, how the login works.

I use the search API to query the devices. The URL looks like this:

https://airwave.flomain.local/ap_search.xml?query=querystring

The only parameter for this request is the “query”. Here you can use every string, you would use in the search from the GUI as well. I use the IP, with only the first octet. like this:

https://airwave.flomain.local/ap_search.xml?query=192.

In the PowerShell script, it looks like this:

#Create the Search URL
$apSearchUri = "https://" + $airwavehost + "/ap_search.xml?query=" + $queryString

#Request the device list and save the answer to a variable
$apsObj = Invoke-RestMethod -Uri $apSearchUri -WebSession $session

The answer is in XML. So I just need to parse the XML answer and write it into a CSV file. Parsing XML and writing it into a CSV file is not related to the RestAPI, so I did not cover this as well. But you can find the whole script on GitHub:

https://github.com/FlorianBaaske/export_airwave_devices

Unfortunately, you cannot add devices to AirWave with the RestAPI, but I’m sure we will see something like this in the future.

Are you working with RestAPI’s? Which language do you prefer for writing such scripts?

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post AirWave RestAPI with PowerShell appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/02/airwave-restapi/feed/ 0 1018
Unified Aruba Controller Discovery https://www.flomain.de/2018/02/unified-aruba-controller-discovery/ https://www.flomain.de/2018/02/unified-aruba-controller-discovery/#respond Wed, 14 Feb 2018 12:30:59 +0000 https://www.flomain.de/?p=993 This time is about some basic things. I will describe the unified Aruba controller discovery process. With the new unified software, the process is the same for IAP and CAP. Actually, with the new unified software, there is no IAP or CAP anymore. The Aruba discovery process is a simple process. The AP uses this […]

The post Unified Aruba Controller Discovery appeared first on Flomain Networking.

]]>
This time is about some basic things. I will describe the unified Aruba controller discovery process. With the new unified software, the process is the same for IAP and CAP. Actually, with the new unified software, there is no IAP or CAP anymore.

The Aruba discovery process is a simple process. The AP uses this process to find a controller or a way to connect to AirWave or Central. Once, the AP found a controller, AirWave or Central it never uses the process again. Except, you do a factory reset on the AP.

The process has 7 plus 1 options. The first 7 options run automatically. The last option is the manual provisioning.

Unified Aruba Controller Discovery: Static Master Assignment

The first and easiest way to discover a controller is the static master assignment. You can do this by manually setting the environment variable during AP boot:

APBoot 1.5.3.14 (build 45815)
Built: 2014-09-05 at 11:23:04

Model: AP-20x
CPU:   BCM53011/15, revision A0
I2C:   ready
SKU:   2
OTP:   0xeca01028
Clock:
       CPU:  800 MHz
       DDR:  533 MHz
       AXI:  400 MHz
       APB:  200 MHz
       PER:  400 MHz
DRAM:  128 MB
POST1: memory passed
SF:    Detected MX25L25635E with page size  4 kB, total 32 MB
Flash: 32 MB
PCIe0: RC, link up
       dev fn venID devID class  rev    MBAR0    MBAR1    MBAR2    MBAR3
       00  00  14e4  4360 00002   03 08000004 00000000 00000000 00000000
PCIe1: RC, link up
       dev fn venID devID class  rev    MBAR0    MBAR1    MBAR2    MBAR3
       00  00  14e4  4360 00002   03 40000004 00000000 00000000 00000000
Power: POE
Net:   eth0
Radio: bcm43460#0, bcm43460#1

Hit  to stop autoboot:  2  0 
apboot> setenv master 10.100.100.50

apboot> printenv 

bootdelay=2
baudrate=9600
autoload=n
boardname=Springbank
servername=aruba-master
bootcmd=boot ap
autostart=yes
bootfile=armv7ns.ari
ethaddr=94:b4:0f:cb:75:cc
ethact=eth0
os_partition=0
stdin=serial
stdout=serial
stderr=serial
master=10.100.100.50

Environment size: 248/65532 bytes
apboot> saveenv 

Saving Environment to Flash...
Erasing flash...Writing to flash..................done
apboot> boot

After boot, the AP connects to the controller with the IP “10.100.100.50” (in my example). This is not handy in large environments and I’m not aware of any customer doing it that way.

I describe this options as well because after the AP uses one of the other options, the controller IP is saved to the same environment variable as above. So, after the AP completes one of the other options, the static assignment option is used for all other reboots.

Unified Aruba Controller Discovery: DHCP Based Discovery

From my point of view, this one is the most used option in the field. The AP tries this options first if no static assignment is present. For IPv4 the AP expects DHCP option 43. If you use IPv6, the AP requests option 52:

Unified Aruba Controller Discovery - IPv6 Option 52

Unified Aruba Controller Discovery – IPv6 Option 52

I will not show the IPv6 setup. But it is the same as with IPv4.

You find the DHCP configuration for a CAP here:

http://www.arubanetworks.com/techdocs/ArubaOS_60/UserGuide/DHCP_Option_43.php

In my case, the DHCP configuration looks like this:

#Aruba Option 43 for CAP
option master code 43 = ip-address;

#Match Option 60
class "ArubaAP-Class" {
        match option vendor-class-identifier;
}

#AP_Management
subnet 10.102.102.0 netmask 255.255.255.0 {
        option routers                  10.102.102.1;
        option subnet-mask              255.255.255.0;
        option domain-search            "flomain.local";
        option domain-name              "flomain.local";
        option domain-name-servers      192.168.2.26;
        subclass "ArubaAP-Class" "ArubaAP" { -->Matches the AP Requests
                option vendor-class-identifier "ArubaAP"; -->Responds with Option 60 "ArubaAP"
                option master           10.100.100.50; -->Set the Master
        }
        range                           10.102.102.10 10.102.102.200;
}

The config above is for the ISC-DHCP-Server on Debian. I create a new option “master”. This option is an IP address. The IP of the controller.

I also create a new class. This class matches all device with a specific “vendor-class-identifier”. DHCP option 60.

In the subnet declaration, I bring both together. The result is the controller IP in the Offer and ACK response from the DHCP server:

Unified Aruba Controller Discovery - Option 43

Unified Aruba Controller Discovery – Option 43

From the AP console it looks like this:

Getting an IP address...
[   21.388000] ADDRCONF(NETDEV_UP): bond0: link is not ready
[   23.392000] bond0: link up (1000FD)
[   23.394000] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
10.102.102.10 255.255.255.0 10.102.102.1
Running ADP...Done. Master is 10.100.100.50

If you cannot use DHCP option 43, go to the next option, ADP.

Unified Aruba Controller Discovery: ADP Based Discovery

If the AP did not get option 43 in the DHCP Offer and/or Ack response but get an IP the AP tries the Aruba Discovery Protocol (ADP) to find a controller. ADP is very simple. The AP just send a broadcast or multicast. I have never seen the multicast option in environments. But the AP sends ADP packets to the multicast group 239.0.82.11. You need to implement multicast routing in the backbone. The controller joins this group as well. But most of the time multicast routing is the show stopper.

Most of the time, my customers use the broadcast option, with the controller in the same VLAN as the AP. If the customer did not use DHCP option 43. This is a simple UDP broadcast:

Unified Aruba Controller Discovery - ADP Broadcast

Unified Aruba Controller Discovery – ADP Broadcast

Unified Aruba Controller Discovery: DNS Based Discovery

This is the second most used option. If the AP can get an IP and can reach a DNS server, this option fits perfectly. The AP tries the options above first, but if they fail, DNS is used.

The AP simply tries to resolve aruba-master.domain.tld. The “domain.tld” part is from the DHCP packet. Put this name into your DNS. The AP will resolve the name and connect to the controller.

Unified Aruba Controller Discovery - DNS Request aruba-master

Unified Aruba Controller Discovery – DNS Request aruba-master

In the screenshot above, you see the DNS queries and afterward the PAPI requests to the controller.

From the CLI it looks like the options above:

Getting an IP address...
[   24.552000] ADDRCONF(NETDEV_UP): bond0: link is not ready
[   26.556000] bond0: link up (1000FD)
[   26.558000] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
10.102.102.10 255.255.255.0 10.102.102.1
Running ADP...Done. Master is 10.100.100.50

Unified Aruba Controller Discovery: Instant VC Discovery

After all the steps above, the AP tries to find another virtual controller (VC). If the AP is in this step, it is in the Instant part of the discovery options. From this stage, the discovery of a controller is only possible after a reboot.

The Instant VC discovery is done through broadcasts. The VC will send UDP broadcasts in the VLAN:

Unified Aruba Controller Discovery - IAP VC Discovery

Unified Aruba Controller Discovery – IAP VC Discovery

If the AP receives such a message, it will connect to the VC, download the full IAP image and restart as an IAP. If no message is received, the AP has not so many options left.

Unified Aruba Controller Discovery: AirWave Discovery

If all the options above fail, the AP is not able to directly connect to a controller (mobility controller or virtual controller(IAP)).

One of the last options is to check DHCP option 43 for information to reach AirWave. The DHCP configuration for this looks like this:

#LAB_IAP
subnet 10.202.202.0 netmask 255.255.255.0 {
        option routers                  10.202.202.254;
        option subnet-mask              255.255.255.0;
        option domain-search            "lab.flomain.local";
        option domain-name              "lab.flomain.local";
        option domain-name-servers      192.168.2.26;
        subclass "ArubaAP-Class" "ArubaInstantAP" {
                option vendor-class-identifier "ArubaInstantAP";
                option airwave          "iap-test,192.168.2.23,aruba123"; -->send the AirWave connection String
        }
        range                           10.202.202.10 10.202.202.200;
}

The option for the AirWave connection string is defined like this:

#Aruba Option 43 for AirWave
option airwave code 43 = string;

The class to match option 60 is defined the same as above for the DHCP based controller discovery.

If the string above is in the DHCP answer from the DHCP server, you see the following in the AP log:

Getting an IP address...
Jan  1 00:00:42 udhcpc[3231]: udhcpc (v0.9.9-pre) started

Jan  1 00:00:43 udhcpc[3231]: send_discover: pkt num 0, secs 0

Jan  1 00:00:43 udhcpc[3231]: Sending discover...

Jan  1 00:00:44 udhcpc[3231]: send_selecting: pkt num 0, secs 2

Jan  1 00:00:44 udhcpc[3231]: Sending select for 10.202.202.13...

Jan  1 00:00:44 udhcpc[3231]: Lease of 10.202.202.13 obtained, lease time 689311

Jan  1 00:00:44 udhcpc[3231]: DHCP OPT 60 is ArubaInstantAP


Jan  1 00:00:44 udhcpc[3231]: DHCP OPT 43, len: 30, buf: iap-test,192.168.2.23,aruba123


Jan  1 00:00:44 udhcpc[3231]: ams-ip: 192.168.2.23, length of ams-key: 8


[   58.601904] ip_time_handler: Got ip and packets on bond0 Started master election 4-0, rand 26
10.202.202.13 255.255.255.0 10.202.202.254

After some time, ca. 5min, the AP starts talking to AirWave and shows up as a new device. The AP will download the full IAP image from AirWave and reboot as an IAP.

Unified Aruba Controller Discovery: Activate

If even AirWave is not working, the AP tries to connect to Activate. First, the AP checks for a new Instant software image. Afterwards, it looks for provisioning rules in Activate. If a rule is found, the AP follows those instructions.

If nothing is there, the AP broadcasts a default SSID “SetMeUp-xx:xx:xx” to allow a manual provisioning of the AP. If this fails as well, the AP reboots and starts from scratch.

Unified Aruba Controller Discovery: Putting all Together

After you know all the single steps, an AP tries to connect to a controller you can decide which one is best for your environment. Keep in mind, the steps are sequentially and not in parallel. Below is an overview of all options:

Unified Aruba Controller Discovery Process

Unified Aruba Controller Discovery Process

What is your preferred discovery method? Let me know as a comment below.

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post Unified Aruba Controller Discovery appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/02/unified-aruba-controller-discovery/feed/ 0 993
How to Protect from Spanning Tree and Loops in the Access Area https://www.flomain.de/2018/01/protect-from-spanning-tree-loops-access-area/ https://www.flomain.de/2018/01/protect-from-spanning-tree-loops-access-area/#comments Wed, 17 Jan 2018 12:30:23 +0000 https://www.flomain.de/?p=981 With modern architectures and campus designs, you do not need spanning tree anymore. But how could you protect from spanning tree BPDU’s and loops in the access area, e.g. from external devices? The classical scenario is the cleaner, putting the free cable into the switch because it is in his way. ArubaOS switches have some […]

The post How to Protect from Spanning Tree and Loops in the Access Area appeared first on Flomain Networking.

]]>
With modern architectures and campus designs, you do not need spanning tree anymore. But how could you protect from spanning tree BPDU’s and loops in the access area, e.g. from external devices?

The classical scenario is the cleaner, putting the free cable into the switch because it is in his way. ArubaOS switches have some good answers to this and other scenarios and protect your network from unwanted loops and spanning tree BPDU’s.

Protect from Spanning Tree and Loops: Loop Protection

The first and easiest one is loop protection. This feature protects from unwanted loops in the access area, e.g. someone connects a cable twice to the same switch. Loop protection use control packets and send these packets out to all ports with loop protection enabled. To do this, the port must have an untagged VLAN. If no untagged VLAN is configured for the port, no control packets are sent. If the switch sees such a packet on another port, the loop is detected. The switch can now shut down the port to avoid network problems.

You configure loop protection on a per-port basis:

switch2(config)# loop-protect 9

This command enables loop protection for port 9. You can check this with this command:

switch2(config)# show loop-protect 

 Status and Counters - Loop Protection Information

  Transmit Interval (sec)     : 1           
  Port Disable Timer (sec)    : 100         
  Loop Detected Trap          : Disabled    
  Loop Protect Mode           : Port        
  Loop Protect Enabled VLANs  :             


       Loop    Loop     Detected  Loop   Time Since  Rx            Port   
  Port Protect Detected on VLAN   Count  Last Loop   Action        Status  
  ---- ------- -------- --------- ------ ----------- ------------- --------
  8    Yes     Yes      NA        1      1d,1h,27... send-disable  Down    
  9    Yes     No       NA        0                  send-disable  Up      

This command also shows the “Time Since Last Loop”. The default behavior is to disable the port which sends the control packet. You can change this to do nothing, or you can disable both ports:

switch2(config)# loop-protect 9 receiver-action 
 send-disable          Disable the sending port when a loop is detected.  This is the default.
 no-disable            Do not disable the sending port when a loop is detected.
 send-recv-dis         Disable the sending and receiving port when a loop is detected.

You might also define how long the port stays in the disable mode:

switch2(config)# loop-protect disable-timer  
 <0-604800>            Enter a number.

0 disables the port forever. Any other value disables the port for the time of the value in seconds.

You can also fine tune the interval, the control packets are sent. The default is a value of 5 seconds. You can narrow it down to 1 second or slow it down to 10 seconds:

switch2(config)# loop-protect transmit-interval 
 <1-10>                Enter a number.

For management purpose, you can send a trap when a loop is detected:

switch2(config)# loop-protect trap loop-detected

From the show command above, you see my default values. Those can be adjusted to your environment.

Below is a control packet:

Protect from Spanning Tree and Loops - Control Packet

Protect from Spanning Tree and Loops – Control Packet

What kind of loops are protected now:

A Loop directly on the Switch:

This is the obvious one. Someone connects the same cable twice, to the same switch.

Protect from Spanning Tree and Loops - Local LoopProtect from Spanning Tree and Loops - Local Loop

Protect from Spanning Tree and Loops – Local Loop

A Loop on a Device connected to the Switch:

This is more tricky. Let’s assume someone connects a switch or even a hub (not sure if you can even buy hubs today) to the access switch and produces a loop there. Loop protection can identify this and blocks the port as well.

Protect from Spanning Tree and Loops - Remote Loop

Protect from Spanning Tree and Loops – Remote Loop

From the packet snipped above, you can see that the destination MAC address is a multicast address. Therefore the unmanaged switch/hub forwards the packet on all ports with the help of the loop, the packet comes back to the access switch.

A loop between two Access Switches:

This scenario assumes, you have at least two access switches and they are connected to each other. A user connects an unmanaged switch/hub to both of the switches.

Protect from Spanning Tree and Loops - Between Two Access Switches

Protect from Spanning Tree and Loops – Between Two Access Switches

Loop protection protects you in this scenario as well. Even if the loop on the unmanaged switch/hub is not present, the ports on the access switches are blocked. But only if both access switches have the same VLAN’s. If the unmanaged switch/hub is in VLAN 1 on “Access Switch1” and VLAN 100 on “Access Switch2” the loop is only detected if “Access Swtich2” knows VLAN 1 or “Access Switch1” knows VLAN 100. One of the VLAN’s, preferably both, are configured on the link between both access switches.

The reason is, that loop protection works with normal multicast L2 frames. As opposed to BPDU’s, those frames are VLAN aware. BPDU’s are always untagged on the port (not true for PVST) and therefore the VLAN does not matter.

In Case of different VLAN’s, you should consider BPDU protection.

Protect from Spanning Tree and Loops: BPDU Filtering

Loop protection helps to protect against loops. But what about misconfigured devices or intruders. Imagine, someone connects a device to the network which is running spanning tree as well. This device is configured to be the root bridge. If you did not have some kind of protection against such devices, they could bring you in trouble by confusing your spanning tree. This could be a denial of service attack to bring you down.

But there is hope. With BPDU filtering you can do something. If you enable BPDU filtering on a port, this port drops all BPDU’s (incoming and outgoing). This means the port is not part of spanning tree at all. And if someone tries to attack you on this port, all BPDU’s are dropped as well. No chance for bad people.

To enable BPDU filtering on a per port basis you enable spanning tree first:

switch2(config)# spanning-tree enable

Afterwards, you enable BPDU filtering:

switch2(config)# spanning-tree 9 bpdu-filter 
The BPDU filter allows the port to go into a continuous
forwarding mode and spanning tree will not interfere, even if
the port would cause a loop to form in the network topology.
If you suddenly experience high traffic load, disable the port
and reconfigure the BPDU filter with the CLI command(s):
"no spanning tree PORT_LIST bpdu-filter"
"no spanning tree PORT_LIST pvst-filter"

Read the warning carefully, because this is important. A port with BPDU filtering enabled will always forward traffic and stays always in forwarding state. When not carefully thinking what you are doing, you can create loops easily.

To check the configuration use this command:

switch2(config)# show spanning-tree 9               

 Multiple Spanning Tree (MST) Information

  STP Enabled   : Yes
  Force Version : MSTP-operation
  IST Mapped VLANs : 1-4094
  Switch MAC Address : 009c02-5dd230
  Switch Priority    : 32768
  Max Age  : 20
  Max Hops : 20   
  Forward Delay : 15

  Topology Change Count  : 10          
  Time Since Last Change : 1 secs      

  CST Root MAC Address : 000b86-be8400
  CST Root Priority    : 32768       
  CST Root Path Cost   : 20000       
  CST Root Port        : 10                 

  IST Regional Root MAC Address : 009c02-5dd230
  IST Regional Root Priority    : 32768       
  IST Regional Root Path Cost   : 0           
  IST Remaining Hops            : 20          

  Root Guard Ports     : 
  Loop Guard Ports     : 
  TCN Guard Ports      : 
  BPDU Protected Ports :                                        
  BPDU Filtered Ports  : 9                                        
  PVST Protected Ports :                                         
  PVST Filtered Ports  :                                         

  Root Inconsistent Ports  :             
  Loop Inconsistent Ports  :             

                 |           Prio              | Designated    Hello         
  Port Type      | Cost      rity State        | Bridge        Time PtP Edge
  ---- --------- + --------- ---- ------------ + ------------- ---- --- ----
  9    100/1000T | 20000     128  Forwarding   | 009c02-5dd230 2    Yes Yes 

If you do a trace on the port, you will see no BPDU’s. If you send BPDU’s to the port, they are dropped without notice.

Protect from Spanning Tree and Loops: BPDU Protection

As opposed to BPDU filtering, BPDU protection protects against incoming BPDU’s. If a BPDU is received, the port is disabled. This makes it a more secure option to protect against external misconfigured devices or bad people, trying to confuse your spanning tree.

To use BPDU protection, you need to enable spanning tree first, like BPDU filtering above. Afterwards, you enable BPDU protection with this command on a per-port basis:

switch2(config)# spanning-tree 9 bpdu-protection

To check the configuration, use the command below:

switch2(config)# show spanning-tree 9

 Multiple Spanning Tree (MST) Information

  STP Enabled   : Yes
  Force Version : MSTP-operation
  IST Mapped VLANs : 1-4094
  Switch MAC Address : 009c02-5dd230
  Switch Priority    : 32768
  Max Age  : 20
  Max Hops : 20   
  Forward Delay : 15

  Topology Change Count  : 28          
  Time Since Last Change : 12 mins     

  CST Root MAC Address : 000b86-be8400
  CST Root Priority    : 32768       
  CST Root Path Cost   : 20000       
  CST Root Port        : 10                 

  IST Regional Root MAC Address : 009c02-5dd230
  IST Regional Root Priority    : 32768       
  IST Regional Root Path Cost   : 0           
  IST Remaining Hops            : 20          

  Root Guard Ports     : 
  Loop Guard Ports     : 
  TCN Guard Ports      : 
  BPDU Protected Ports : 9                                       
  BPDU Filtered Ports  :                                         
  PVST Protected Ports :                                         
  PVST Filtered Ports  :                                         

  Root Inconsistent Ports  :             
  Loop Inconsistent Ports  :             

                 |           Prio              | Designated    Hello         
  Port Type      | Cost      rity State        | Bridge        Time PtP Edge
  ---- --------- + --------- ---- ------------ + ------------- ---- --- ----
  9    100/1000T | 20000     128  Forwarding   | 009c02-5dd230 2    Yes Yes

If you trace the port, you see a lot of STP messages. But, if you answer them or send BPDU’s the port gets into the “BPDU Error” state:

switch2(config)# show spanning-tree 9

 Multiple Spanning Tree (MST) Information

  STP Enabled   : Yes
  Force Version : MSTP-operation
  IST Mapped VLANs : 1-4094
  Switch MAC Address : 009c02-5dd230
  Switch Priority    : 32768
  Max Age  : 20
  Max Hops : 20   
  Forward Delay : 15

  Topology Change Count  : 28          
  Time Since Last Change : 19 mins     

  CST Root MAC Address : 000b86-be8400
  CST Root Priority    : 32768       
  CST Root Path Cost   : 20000       
  CST Root Port        : 10                 

  IST Regional Root MAC Address : 009c02-5dd230
  IST Regional Root Priority    : 32768       
  IST Regional Root Path Cost   : 0           
  IST Remaining Hops            : 20          

  Root Guard Ports     : 
  Loop Guard Ports     : 
  TCN Guard Ports      : 
  BPDU Protected Ports : 9                                       
  BPDU Filtered Ports  :                                         
  PVST Protected Ports :                                         
  PVST Filtered Ports  :                                         

  Root Inconsistent Ports  :             
  Loop Inconsistent Ports  :             

                 |           Prio              | Designated    Hello         
  Port Type      | Cost      rity State        | Bridge        Time PtP Edge
  ---- --------- + --------- ---- ------------ + ------------- ---- --- ----
  9    100/1000T | 20000     128  BpduError    |               2    Yes No  

Any port in this state will be disabled forever. Or until you enable the port manually:

switch2(config)# interface 9 enable

To change this behavior you can set a global timeout period:

switch2(config)# spanning-tree bpdu-protection-timeout 60

The command above set the timeout for the port. If the port receives a BPDU, the port is set to “BpduError” state for the time in the timeout. Afterwards, the port is set into the enable state again.

The last option is for monitoring. With the command below you tell the switch to send a trap upon receiving a BPDU:

switch2(config)# spanning-tree trap errant-bpdu

My recommendation is to use BPDU filter on all ports to other switches. So, on all uplinks. And BPDU protection on all other ports. This protects you from bad BPDU from outside of your environment. I assume that you do not use STP in your environment for loop protection between switches, because of technologies like VSF or IRF. If you do not use such technologies but STP, do not use BPDU filter on uplinks.

Do you use STP in your environment? Why, or why not? Tell me in the comment section below.

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post How to Protect from Spanning Tree and Loops in the Access Area appeared first on Flomain Networking.

]]>
https://www.flomain.de/2018/01/protect-from-spanning-tree-loops-access-area/feed/ 1 981
ArubaOS 8 – Controller Deployment https://www.flomain.de/2017/12/arubaos-8-controller-deployment/ https://www.flomain.de/2017/12/arubaos-8-controller-deployment/#comments Wed, 06 Dec 2017 12:30:27 +0000 https://www.flomain.de/?p=713 In this post, I describe the different ways to deploy a controller with ArubaOS 8. Controller Deployment is significantly easier with ArubaOS 8 and it is the first time, that we see Zero Touch Provisioning for controllers. With ArubaOS 6.x it was not possible to have a complete Zero Touch Provisioning process. The fact, that […]

The post ArubaOS 8 – Controller Deployment appeared first on Flomain Networking.

]]>
In this post, I describe the different ways to deploy a controller with ArubaOS 8. Controller Deployment is significantly easier with ArubaOS 8 and it is the first time, that we see Zero Touch Provisioning for controllers.

With ArubaOS 6.x it was not possible to have a complete Zero Touch Provisioning process. The fact, that you have to configure stuff like the IP of the local controller, made this impossible. With ArubaOS 8 you configure everything on the Mobility Master (MM). There is no need to configure something on the controller. You even have no chance to. The configuration mode is blocked.

Nevertheless, you have the option to deploy the controller the old way. This is the first part of this post. Afterwards, I show you how the Zero Touch Provisioning works.

Controller Deployment: The Manual Way with PSK

The first part is about the manual deployment of controllers. This is still possible and much faster than with 6.x.

I assume, that you have the MM up and running and IP connectivity is possible between the Managed Device (MD) and the MM.

The communication between MM and MD is protected with IPSec. In my case, I use IPSec with PSK. You can also use certificates. In this scenario, I use the PSK option. Therefore you need to make the MM aware of the PSK. Connect to the MM and create the PSK:

(MM) *[mynode] #cd /mm
(MM) *[mm] #configure terminal 
Enter Configuration commands, one per line. End with CNTL/Z
(MM) *[mm] (config) #localip 10.201.201.10 ipsec comcomcom

I always create the PSK at the “mm” level. If you have multiple MM controller, this makes the configuration on all of them.

In this setup, the MD has a static IP. If you need to have a dynamic IP for the MD you can use the MAC for authentication, instead of the IP:

(MM) *[mm] (config) #local-peer-mac 00:0c:29:35:c2:cf ipsec test123

The “local-peer-mac” is the MAC of the MD. If the MD is a hardware controller you need to use the MAC from the VLAN interface, which is used to connect to the MM. If the MD is a virtual controller, you need to use the MAC from the management interface.

You need the MAC address to arrange the controller in the configuration hierarchy, as well. My current hierarchy has a folder named “LAB”:

(MM) *[00:0b:86:be:84:00] (config) #show configuration node-hierarchy 

Default-node is not configured. Autopark is disabled.

Configuration node hierarchy
----------------------------
Config Node                      Type    Name
-----------                      ----    ----
/                                System  
/md                              System  
/md/Haan-Live                    Group   
/md/Haan-Live/00:0b:86:be:84:00  Device  wlan-controller
/md/LAB                          Group   
/mm                              System  
/mm/mynode                       System  

I will place the new controller in the folder “LAB”:

(MM) *[mm] (config) #configuration device 00:0C:29:35:C2:CF device-model MC-VA /md/LAB 
(MM) *[mm] (config) #show configuration node-hierarchy 

Default-node is not configured. Autopark is disabled.

Configuration node hierarchy
----------------------------
Config Node                      Type    Name
-----------                      ----    ----
/                                System  
/md                              System  
/md/Haan-Live                    Group   
/md/Haan-Live/00:0b:86:be:84:00  Device  wlan-controller
/md/LAB                          Group   
/md/LAB/00:0c:29:35:c2:cf        Device  
/mm                              System  
/mm/mynode                       System

I create the new device with the first command. The second one is to check. The new device has no “Name”. After the device connects to the MM, this field is populated as well with the hostname of the MD.

Now, it is time to start the MD.

During bootup of the MD you have the chance to configure all options to connect to the MM:

Controller Deployment - Manual Configuration

Controller Deployment – Manual Configuration

The scenario above is for one MM without a VPN concentrator. I will build this in a later post. The scenario is also only for the “PSKwithIP” option. If you choose the MAC for authentication you need to change this to “PSKwithMAC”.

The most important pieces of information are the IP of the MD, the IP of the MM and the shared secret. You can change the rest afterward on the MM anyway. But those are important to initially connect to the MM.

You accept the configuration at the end and the MD starts rebooting. Afterward, the MD connects to the MM using IPSec and gets the configuration from the “Group” “/md/LAB”:

(MM) *[mynode] #show switches 

All Switches
------------
IP Address     IPv6 Address  Name             Location          Type    Model       Version        Status  Configuration State  Config Sync Time (sec)  Config ID
----------     ------------  ----             --------          ----    -----       -------        ------  -------------------  ----------------------  ---------
192.168.2.70   None          MM               Building1.floor1  master  ArubaMM-VA  8.1.0.2_60858  up      UPDATE SUCCESSFUL    0                       363
10.201.201.10  None          LAB_1            Building1.floor1  MD      ArubaMC-VA  8.1.0.2_60858  up      UPDATE SUCCESSFUL    10                      363
192.168.2.50   None          wlan-controller  Building1.floor1  MD      Aruba7005   8.1.0.2_60858  up      UPDATE SUCCESSFUL    20                      363

Total Switches:3

Controller Deployment: The Manual Way with Certificate

To use a PSK for authentication is not the best way. So, to improve the situation, you can use a certificate for the IPSec connection. With the CLI wizard, it is not possible to use a certificate for IPSec during the initial configuration tasks. But, you can change this afterward. Choose either “PSKwithIP” or “PSKwithMAC” from above and wait until the controller is fully connected to the MM.

To make this work, you have to create certificates for the MM and all MD’s. In my lab, I use the CA from ClearPass. You can use whatever you like to create the certificates, but keep one thing in mind. The subject of the certificate has to include the MAC of the controller. The MAC, you use, in the commands to configure the MD<–>MM connection later on.

You need 2 certificates for every controller. The root CA certificate and a client certificate. The root CA certificate is the same for all controllers. The client certificate is unique and has the controller MAC address in the subject.

Upload the certificates to the controller. This is the same for every MM and MD. Just different levels of the hierarchy. To upload the client certificate to an MD or MM select the MD or MM in the hierarchy and go to “Configuration–>System–>Certificates–>Import Certificates”:

Controller Deployment - Import Certificate

Controller Deployment – Import Certificate

Select a unique “Certificate Name” and select the certificate from your computer. The certificate includes a private key. A passphrase protects this key. You specify the passphrase during export or creation of the certificate. Enter the passphrase as well. Without the passphrase, the controller is not able to get the private key and cannot use the certificate. Select the “Certificate format” and the “Certificate type”. The client certificate is always a “ServerCert” and the root CA certificate is always “TrustedCA”. Click the submit button to upload the certificate. Do this for all MD’s and the MM.

Next step is to create an entry for MD with a custom certificate on the MM:

(MM) ^*[mm] (config) # local-custom-cert local-mac 00:0b:86:be:84:00  ca-cert flomain-root server-cert mm-mac

Now, you can change the connection settings for the MD with this command in the MD context:

(MM) *[00:0b:86:be:84:00] (config) #masterip 192.168.2.70 ipsec-custom-cert master-mac-1-c 00:0c:29:c7:29:3b ca-cert flomain-root server-cert wlan-controller-mac interface vlan 1

The controller will reboot and use the custom certificate for the connection.

To check if a certificate is used for the authentication, use this command:

(MM) *[mynode] #show crypto isakmp sa 

ISAKMP SA Active Session Information
------------------------------------
Initiator IP                              Responder IP                              Flags       Start Time      Private IP     
------------                              ------------                              -----     ---------------   ----------     
192.168.2.50                              192.168.2.70                              r-v2-c    Nov 15 21:34:12     -                                       

Flags: i = Initiator; r = Responder
       m = Main Mode; a = Agressive Mode; v2 = IKEv2
       p = Pre-shared key; c = Certificate/RSA Signature; e =  ECDSA Signature
       x = XAuth Enabled; y = Mode-Config Enabled; E = EAP Enabled
       3 = 3rd party AP; C = Campus AP; R = RAP;  Ru = Custom Certificate RAP; I = IAP
       V = VIA; S = VIA over TCP

Total ISAKMP SAs: 1

The “c” flag indicates, that you use a certificate. To check which certificate, use this command:

(MM) *[mynode] #show crypto isakmp sa peer 192.168.2.50

 Initiator IP: 192.168.2.50
 Responder IP: 192.168.2.70
 Initiator: No
 Initiator cookie:5081e3cdf4f0f5c9 Responder cookie:be8ad9caa747eef7
 SA Creation Date: Wed Nov 15 21:34:13 2017
 Life secs: 28800
 Initiator Phase1 ID: C=DE S=NRW L=Haan O=Flomain OU=WLAN Controller (7005) CN=00:0b:86:be:84:00 E=flo@flomain.de
 Responder Phase1 ID: C=DE S=NRW L=Haan O=Flomain OU=WLAN Controller (VMM) CN=00:0C:29:C7:29:3B E=flo@flomain.de
 Exchange Type: IKE_SA (IKEV2) 
 Phase1 Transform:EncrAlg:AES128 HashAlg:HMAC_SHA1_96 DHGroup:2 
 Authentication Method: RSA Digital Signature 4096-bits
 IPSEC SA Rekey Number: 0
 Ipsec-map name: default-local-master-ipsecmap-00:0b:86:be:84:00
 
(MM) *[mynode] #

You cannot see the name of the certificate but from the “Initiator Phase1 ID” and the “Responder Phase1 ID” you can get the subjects for both certificates. And those match my certificates.

Controller Deployment: ZTP with Activate

To deploy controllers without touching them, you use Activate. Activate is a cloud-based tool to provision devices.

I assume that you are somehow familiar with Activate. The first step is to add the MD to Activate. This step is an automatic process. Aruba adds any device to your Activate account which is ordered from you.

After the device is in Activate, move it to the “Folder” of choice. All devices in this “Folder” get the same provisioning rule.

Create a new “Provisioning Rule” in Activate for the folder with the MD. Change to the “Setup” view and select the folder with the MD. Now click the “New” link in the “Rules” section:

Controller Deployment - Create Provisioning Rule in Activate

Controller Deployment – Create Provisioning Rule in Activate

Select the “Folder” with the MD as the “Parent Folder”. The “Provisioning Type” is “Managed Device to Master Controller”. I do not have any redundancy. But here you can select the type of your redundancy, with “Redundancy Level”. Put the node path into the “Config Node Path” field. This is the hierarchy level on the MM, where the device will be placed. Now, you select the MM mac address from the list of “Master Controller”. This assumes the MM is in Activate as well. You cannot use the ZTP with Activate if you did not add the MM to Activate as well. Also, specify the IP of the MM in “Master Controller IP”. You can also change the “Rule Name” if you need.

For monitoring purposes I also add a “Rule” to notify me of any new provisioning event:

Controller Deployment - Create Monitoring Rule in Activate

Controller Deployment – Create Monitoring Rule in Activate

You simply select the provisioning rule, which triggers the mail notification.

Now, let’s go to the MM. You need to configure Activate in the MM. This is my Activate configuration:

activate
    whitelist-enable
    username "mail@no-spam.com"
    password 60f72ede33b80f645d6d0dbf00a1edb6353552f8727a3f56

“username” and “password” are your Activate credentials. You check the configuration with the following command:

(MM) *[mynode] #show activate 

activate
--------
Parameter                                        Value
---------                                        -----
Activate AP Whitelist Service                    Enabled
Activate Device Whitelist Service                Enabled
Activate URL                                     https://activate.arubanetworks.com/
Provision Activate URL                           https://device.arubanetworks.com/
Activate Login Username                          mail@no-spam.com
Activate Login Password                          ********
Periodic Interval for AP WhiteList Download      1
Periodic Interval for Device WhiteList Download  24
Add-Only Operation                               Enabled
Custom cert to upload to Activate                N/A
Server cert to be used for IPSEC                 N/A

To trigger a sync use this command:

(MM) *[mynode] #activate sync

Now, let’s start the MD. The MD boots up and offers you the wizard, from the scenario above. This time, do not enter anything and wait for the MD to connect to Activate:

Starting auto provisioning
Registered for NTP Sync
Using port gigabitethernet 0/0/1 for auto provisioning
Initiated DHCP, awaiting DHCP response

Auto-provisioning is in progress. It requires DHCP and Activate servers
Choose one of the following options to override or debug auto-provisioning...
    'enable-debug'  : Enable auto-provisioning debug logs
    'disable-debug' : Disable auto-provisioning debug logs
    'mini-setup'    : Start mini setup dialog. Provides minimal customization and requires DHCP server
    'full-setup'    : Start full setup dialog. Provides full customization

Enter Option (partial string is acceptable): 

Received DHCP response, My IP = 10.201.201.206, Mask = 255.255.255.0, GW = 10.201.201.254, DNS = 192.168.2.26
Master info not received from DHCP, trying activate
Provisioning Parameters not received from Activate, will retry after 30 secondsReceived Activate response, My Role = md, Master  = 10.100.100.70, Master MAC = 00:0C:29:C7:29:31, Hostname = 7205-Test, Country code = DE, Redundant Master MAC = none, VPN IP = none, VPN MAC = none, Redundant VPN MAC = none, Secondary Master = none, Secondary Master Mac = none, Redundant Secondary Master Mac = none, Secondary VPN IP = none, Secondary VPN MAC = none, Secondary Redundant VPN MAC = none 
Master = 10.100.100.70 auto-discovered from Activate

copying ca-cert


[20:23:39]:Starting rebootme

The MD get all the information from Activate. These are the information from the provisioning rule, from above. But also the ca-certificate from the MM. To check the certificate from the MM, the MD needs this ca certificate. The MM uploads the ca certificate during the initial sync with Activate.  After the MD has all the information, it reboots. During this time you can check the MM config and search for the new MD:

(MM) *[mm] #show running-config | include local-custom 
Building Configuration...
local-custom-cert local-mac "00:1a:1e:03:21:28" ca-cert factory-ca-cert server-cert self-signed-field-cert

and

(MM) *[mm] #show local-cert-mac 


Local Switches configured by Local Certificate
-----------------------------------------------
Switch IP of the Local  MAC address of the Local  Cert-Type    CA cert          Server cert
----------------------  ------------------------  ---------    -------          -----------
                        00:1a:1e:03:21:28         SS Internal  Factory-CA-Cert  Self-Signed-Server-Cert
                        00:0b:86:be:84:00         Custom       flomain-root     mm-mac
                        00:0c:29:35:c2:c5         Custom       flomain-root     Factory-Server-Cert

Here you see the difference in using a custom certificate or the self-signed certificates for the MM<–>MD connection. This is the MD part if the config:

masterip 10.100.100.70 ipsec-custom-cert master-mac-1-c 00:0C:29:C7:29:31 ca-cert sc-root-ca server-cert factory-cert interface vlan 4094

That is everything. Without ever touching the MD it is up and running on the MM.

Did you use the ZTP function of ArubaOS 8? Or any other ZTP functions of the other products. Tell me what you love about this feature and what you would change to make it even better.

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post ArubaOS 8 – Controller Deployment appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/12/arubaos-8-controller-deployment/feed/ 2 713
Master Standby with ArubaOS 8 https://www.flomain.de/2017/11/master-standby-arubaos-8/ https://www.flomain.de/2017/11/master-standby-arubaos-8/#comments Wed, 29 Nov 2017 12:32:19 +0000 https://www.flomain.de/?p=951 In the last posts about ArubaOS 8, I talked a lot about Virtual Mobility Master. This time, I will not include the VMM in my scenario. The reason is simple. Many customers deploy two controllers today. They simply do not need more. So the big question is how to build an environment with ArubaOS 8 and […]

The post Master Standby with ArubaOS 8 appeared first on Flomain Networking.

]]>
In the last posts about ArubaOS 8, I talked a lot about Virtual Mobility Master. This time, I will not include the VMM in my scenario. The reason is simple. Many customers deploy two controllers today. They simply do not need more. So the big question is how to build an environment with ArubaOS 8 and two controllers. The answer is Master Standby. Likely the same design as with ArubaOS 6.x.

Just to make it clear, you get the most features, the most benefits and the most outcome from a deployment with VMM. So this is just a plan B if you cannot use the benefits of an implementation with VMM.

Master Standby: Requirements

The Master Standby design requires two controllers, obviously. They run in the standalone mode. Keep this in mind during the setup of the controller. Only the active controller can terminate AP’s in this design. But you can use a variation of the fast failover feature.

The design looks like this, from a logical point of view:

Master Standby - Design

Master Standby – Design

The two controller run in standalone mode. I use the master redundancy configuration to synchronize the configuration, user data and of course the licenses. If the master fails, you can use the licenses on the standby for 30 days. Enough time to recover.

To create minimal downtimes during failover, I also create an HA Group. With the HA Group configuration, the AP’s creates a tunnel to each of the controllers. During failover, the AP fails over to the tunnel to the standby controller. This works without a reboot of the AP. Even the radios stay active.

Sounds interesting to you? Read further.

Master Standby: Master Redundancy

The first step to build the above design is to create the master redundancy. To start with master redundancy, I assume you have the two controllers running in standalone mode. Preferably fresh vom the factory or after a factory reset. You have configured them with the initial setup wizard to standalone controllers and they have rebooted.

Login to the one, which will be the active master. In the future, I name them master and standby. On the master, go to “Configuration–>Services–>Redundancy” and select the “Virtual Routing Table”.  Make sure, you are in the device hierarchy and not in the “Mobility Controller” hierarchy. Add a new “Virtual Router” with the “+” sign:

Master Standby - Create VRRP

Master Standby – Create VRRP

Use a meaningful “Description” to avoid confusion later on. I always use the VLAN ID for the “ID”. This assumes I use VLAN 201. This is my controller management VLAN. So both controllers have IP addresses in that VLAN and the controller IP is in this VLAN as well. Enter an “Authentication password” and specify the VRRP “IP address”.  I set the “Priority” of the master to 110, to make sure he is always the master. I also use pre-emption to make sure the master is master again after he is back. Set the “Admin state” to up and select the VLAN.

“Submit” the configuration and configure the same, except for the priority, on the standby. For priority use the value of 100, which is the default.

After some seconds, VRRP is up and running. You can check on the CLI:

(Master) [mynode] (config) #show vrrp


Virtual Router 201:
    Description Master VRRP
    Admin State UP, VR State MASTER
    IP Address 10.201.201.10, MAC Address 00:00:5e:00:01:c9, vlan 201
    Priority 110, Advertisement 1 sec, Preemption Enable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled
(Standby) *[mynode] (config) #show vrrp


Virtual Router 201:
    Description 
    Admin State UP, VR State BACKUP
    IP Address 10.201.201.10, MAC Address 00:00:5e:00:01:c9, vlan 201
    Priority 100, Advertisement 1 sec, Preemption Enable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled

The next step is to enable database synchronization. On the master, go to the “Mobility Controller” configuration hierarchy and go to “Configuration–>Services–>Redundancy” and select “Master Redundancy”:

Master Standby - Database Synchronization

Master Standby – Database Synchronization

“Submit” the changes and go down to the controller hierarchy again, but the same configuration page:

Master Standby - Create Master Redundancy

Master Standby – Create Master Redundancy

Add the “Master VRRP” information, this is the VRRP from above and the “IP address of the peer”. This is the IP of the standby. For this lab, I use an “IPSec Key” for “Authentication”. Certificates are possible as well. “Submit” the changes and redo the configuration on the standby, except for the IP address. Here you use the IP of the master. It could take some minutes to form the master redundancy. To check if it is up and running use the command below:

(Master) [mynode] #show database synchronize 

Last L2 synchronization time: Mon Nov 27 04:41:29 2017
Last L3 synchronization time: Secondary not synchronized since last reboot
To Master Switch at 10.201.201.12:  succeeded
To Secondary Master Switch at unknown IP address:  succeeded
WMS Database backup file size: 31093 bytes
Local User Database backup file size: 38393 bytes
Global AP Database backup file size: 12953 bytes
IAP Database backup file size: 3750 bytes
Airgroup Database backup file size: 3052 bytes
License Database backup file size: 5168 bytes
CPSec Database backup file size: 3224 bytes
L2 Synchronization took 2 second
L3 Synchronization took less than one second

16 L2 synchronization attempted
15 L2 synchronization have failed

0 L3 synchronization attempted
0 L3 synchronization have failed

L2 Periodic synchronization is enabled and runs every 1 minute

L3 Periodic synchronization is disabled

Synchronization doesn't include Captive Portal Custom data
(Standby) *[mynode] #show database synchronize 

Last L2 synchronization time: Mon Nov 27 04:41:22 2017
From Master Switch at 10.201.201.11:  succeeded
WMS Database backup file size: 31093 bytes
Local User Database backup file size: 38393 bytes
Global AP Database backup file size: 12953 bytes
IAP Database backup file size: 3750 bytes
Airgroup Database backup file size: 3052 bytes
License Database backup file size: 5168 bytes
CPSec Database backup file size: 3224 bytes
L2 Synchronization took 1 second

8 L2 synchronization attempted
6 L2 synchronization have failed

L2 Periodic synchronization is enabled and runs every 1 minute

Synchronization doesn't include Captive Portal Custom data

I have set the synchronization time to 1 minute. This is to make the waiting time shorter. In production environments, 10 minutes is ok as well.

You could now connect an AP. You would use the VRRP address for the connection between AP and controller. During a failover, the AP would connect to the standby after VRRP changes. But the AP would reboot. To avoid this, we use “HA Groups”.

Master Standby: HA Groups

The “HA Group” feature enables fast failover. To do this, the AP creates a tunnel to the two controllers. The first tunnel is the active one. If the controller for tunnel one fails, the AP uses tunnel two to the second controller. This makes the failover time very short and the best, the AP did not reboot during the failover.

To create an “HA Group”, login to the master controller. Stay in the “Mobility Controller” hierarchy and go to “Configuration–>Services–>Redundancy” and select “HA Groups”. Create a new “HA Group” with the “+” sign:

Master Standby - Create HA Group

Master Standby – Create HA Group

Add the two controllers to the “HA Group”. You can use the role “dual”. “Active” for the master and “Standby” for the standby works as well. Enable “Pre-emption” and “State synchronization”. Enter a “Pre-shared-key” and “Submit” the changes.

The last step is to join the controllers to the group. Stay on the same page as bevor and select “HA Member”:

Master Standby - HA Member

Master Standby – HA Member

 

Select the “HA Group” from the drop-down list “Member of HA group”. Now, the two controllers form an “HA Group”.

You also have to change the LMS IP in the AP group. You can do this in the AP Systems profile as well. I personally, prefer the group. In the same hierarchy level go to “Configuration–>AP Groups” and select the AP group you would like to change:

Master Standby - LMS IP

Master Standby – LMS IP

Select the “LMS” tab and enter the two IP addresses of the two controllers. The master the first one and the standby is the “Backup IP address”. Save the configuration.

All AP’s establish now two connections. One to each controller. To check this use the command below:

(Master) [mynode] #show ha ap table 

HA AP Table
-----------
AP       IP-Address      MAC-Address        AP-flags  HA-flags
--       ----------      -----------        --------  --------
HA-Test  10.201.201.204  94:b4:0f:cb:75:cc  LU        

Total Num APs::1
Active APs::1
Standby APs::0
AP Flags: R=RAP; S=Standby; s=Bridge Split VAP L=Licensed; M=Mesh, U=Up
HA Flags: S=Standby, C=Standby connected, L=LMS, F=Sent Failover Request to AP, H=AP flaged for Inter Controller Heartbeat
(Standby) *[mynode] (config-submode)#show ha ap table

HA AP Table
-----------
AP       IP-Address      MAC-Address        AP-flags  HA-flags
--       ----------      -----------        --------  --------
HA-Test  10.201.201.204  94:b4:0f:cb:75:cc  SLU       

Total Num APs::1
Active APs::0
Standby APs::1
AP Flags: R=RAP; S=Standby; s=Bridge Split VAP L=Licensed; M=Mesh, U=Up
HA Flags: S=Standby, C=Standby connected, L=LMS, F=Sent Failover Request to AP, H=AP flaged for Inter Controller Heartbeat

You see, that the AP is “Licensed” and “Up” in the master and in addition “Standby” on the standby controller. In case of a failure, the AP uses the standby connection to stay active. Because if the synchronization, all user sessions are available on the standby as well. No need for a complete new authentication.

Once the master is back online. All the master functions change back, including the AP termination.

The user might see a small interruption, I had only 8 pings failing in the worst case. Normally around 3-5.

Do you use this design of master standby or do you prefer a design with virtual mobility master? Tell me and leave a comment below.

If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.

The post Master Standby with ArubaOS 8 appeared first on Flomain Networking.

]]>
https://www.flomain.de/2017/11/master-standby-arubaos-8/feed/ 23 951