Tag Archives: LDAP

FortiGate LDAPS Authentication Failure

Posted on by
2

KB ID 0001733

Problem

Here’s a brief one that tripped me up a couple of weeks ago, I was deploying FortiGate LDAPS authentication for some FortiClient SSL VPN connections into a FortiGate firewall like so;

Despite my best efforts I was getting authentication failures? If I tested the username and password in the GUI web management portal, that worked fine?

Testing FortiGate LDAPS

First step is to test authentication at command line, like so;

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' failed!

[/box]

Note: My-DC is the domain controller, test, user is the username, and Password123 is the password for my AD user. (The fact I need to explain that is depressing, but c’est la vie).

So despite what the GUI is telling me, authentication is actually failing, remember I’m using LDAPS, so the FortiGate needs to have the CA certificate, (that issued the Kerberos certificates on my domain controller(s)), in its trusted CA list! And TCP port 636 needs to be open between the firewall and the domain controllers.

Debugging FortiGate LDAPS

So now we need to debug what’s going on;

[box]

Forti-FW # diagnose debug enable
Forti-FW # diagnose debug application fnbamd 255
Debug messages will be on for 30 minutes.

[/box]

Then simply attempt to authenticate via FortiClient, or recall the ‘diag test’ command from above.

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
[1932] handle_req-Rcvd auth req 1296531457 for test.user in My-DC opt=0000001b prot=0
[424] __compose_group_list_from_req-Group 'My-DC', type 1
[617] fnbamd_pop3_start-test.user
[970] __fnbamd_cfg_get_ldap_list_by_server-
[976] __fnbamd_cfg_get_ldap_list_by_server-Loaded LDAP server 'My-DC'
[1131] fnbamd_cfg_get_ldap_list-Total ldap servers to try: 1
[1713] fnbamd_ldap_init-search filter is: sAMAccountName=test.user
[1722] fnbamd_ldap_init-search base is: dc=testbench,dc=co,dc=uk
[1146] __fnbamd_ldap_dns_cb-Resolved My-DC:192.168.1.122 to 192.168.1.122, cur stack size:1
[919] __fnbamd_ldap_get_next_addr-
[1152] __fnbamd_ldap_dns_cb-Connection starts My-DC:192.168.1.122, addr 192.168.1.122 over SSL
[874] __fnbamd_ldap_start_conn-Still connecting 192.168.1.122.
[591] create_auth_session-Total 1 server(s) to try
[1097] __ldap_connect-tcps_connect(192.168.1.122) failed: ssl_connect() failed: 337047686 (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed).
[930] __ldap_error-My-DC:192.168.1.122, addr 192.168.1.122
[725] __ldap_stop-Conn with 192.168.1.122 destroyed.
[919] __fnbamd_ldap_get_next_addr-
[902] __ldap_try_next_server-No more server to try for 'My-DC'.
[785] __ldap_done-svr 'My-DC'
[755] __ldap_destroy-
[2870] fnbamd_ldap_result-Error (3) for req 1296531457
[217] fnbamd_comm_send_result-Sending result 3 (nid 0) for req 1296531457, len=2044
authenticate 'test.user' against 'My-DC' failed!
Forti-FW # [747] destroy_auth_session-delete session 1296531457
[755] __ldap_destroy-
[1764] fnbamd_ldap_auth_ctx_free-Freeing 'My-DC' ctx
[2099] fnbamd_ldap_free-Freeing 'My-DC'

[/box]

OK so it’s SSL related? For SSL to work you need the following;

  1. To trust the CA that issued the certificate
  2. To be able to resolve (via DNS) the common name (or Subject Alternative Name) on the certificate
  3. If you’ve specified the LDAP server by IP address the IP address of the server needs to be on the certificate as a Subject Alternative Name (SAN).
  4. Your firewall and the AD/LDAP server need to have compatible SSL ciphers.

So I had number 1 covered, and the chance of it being number 4 are rare, (server and firewall are fully updated).

So my problem was initially number 2 I’d specified the LDAPS server via its internal IP. I needed to use its FQDN, then of course the firewall needed to be able to resolve that IP with a DNS lookup (try execute ping server-name.doman-name if you’re unsure!)

[box]

Forti-FW # execute ping win-server.testbench.co.uk
Unable to resolve hostname.  <---OOPS THAT'S NOT GOOD!

Forti-FW # execute ping 192.168.1.122 <---CONNECTIVITY IS OK!
PING 192.168.1.122 (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=5.4 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.0 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=1.9 ms
^C
--- 192.168.1.122 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.9/3.1/5.4 ms

[/box]

Once DNS was setup correctly;

[box]

Forti-FW # execute ping win-server.testbench.co.uk
PING win-server.testbench.co.uk (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=1.9 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.3 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=2.1 ms
^C
--- win-server.testbench.co.uk ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss <---BOOM THAT'S BETTER
round-trip min/avg/max = 1.9/2.1/2.3 ms

[/box]

Then retest.

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' succeeded!
Group membership(s) - CN=GS-VPN-Users,OU=Securty-Groups,DC=testbench,DC=co,DC=uk
                      CN=Domain Users,CN=Users,DC=testbench,DC=co,DC=uk

[/box]

Related Articles, References, Credits, or External Links

NA

Duo: Migrate from LDAP to LDAPS

Posted on by
3

KB ID 0001647

Problem

With the impending ‘turning off’ of cleartext LDAP queries to Windows Server, I wanted to make sure my new Duo deployments were already using LDAPS. I got LDAP deployed very quickly and easily, but making the ‘swap’ to LDAPS proved to be massively problematic.

Normally I find Duo a pleasure to deploy, but their technical documentation just confused me for this and I went running up some blind alleys, and eventually ended up logging a call to Duo to try to get it working. So to save you this pain, read on.

Solution

Firstly your domain controller(s) need to be setup to accept LDAPS queries, SORT THAT OUT FIRST. I’ve covered that in the following post;

Get Ready for LDAPS Channel Binding

In the following section I’ll assume you have LDAP already setup on your Duo ADSync, if this is a new deployment, and you are going straight to LDAPS, then you can ignore this next section.

Duo Existing LDAP AD Sync

It goes without saying, (but I’ll say it anyway,) your ADSync should already be connected, if you’re switching room LDAP!

So your domain controller(s) will be using TCP port 389.

Your transport type will be set to ‘Clear’.

Duo Deploy LDAPS for ADSync

The first thing that held me up was reading the Duo documentation, and wondering what I needed to add to my authproxy.cfg file! The truth is;

YOU DON T NEED TO ADD ANYTHING TO AUTHPROXY.CFG!!

Here’s a copy of mine for reference, you ONLY need the sections highlighted, the additional section on mine was for my Cisco ASA RADIUS client;

Rights and Permissions for Duo Service Account

Note: By default the Duo service on your Duo Auth Proxy server will be running under the LOCAL SYSTEM ACCOUNT. I had problems using this account, so I used the service account specified in the authproxy.cfg file. But there are some rights you need to assign to the account first. On the Auth Proxy server, run secpol.msc > Security Settings > Local Policies > User Rights Assignment > Log on as a service > Add User or Group > Add in your Duo service account.

 

All domain users should have the following right, but let’s take a ‘belt and braces’ approach! On a domain controller open ‘Active Directory Users and Computers’ > Right click your domain > Properties > Security > Advanced.

Add in the Duo service account, and grant;

  • List contents
  • Read all properties
  • Read properties

Note: They will probably, already be selected.

Finally: Add the Duo service account to the LOCAL ADMINISTRATORS group on the Duo Auth Proxy server, (Server Manager > Tools > Computer Management).

You can now open the services console and change the account the service runs under, to the Duo Service account, (Windows Key + R > services.msc > OK > Locate ‘Duo Authentication Proxy Service’ > Properties > Log On > Change the account to your service account and enter the password.) Then RESTART THE SERVICE.

Change Duo ADSync to LDAPS

To do this you are going to need a copy of your Root CA certificate (in PEM format). If you have Microsoft Certificate services make sure you get a copy of the Root CA cert in Base 64 format, (if you don’t, when you open the Certificate with Notepad, it will link like gobbledegook!)

Open your Cert with a text editor, and it should look a bit like this, copy that, (with no additional spaces on the end!) To the clipboard, you will need to paste it into the Duo Admin Panel in a minute.

In the Duo Amin Portal > Users > Directory Sync > Active Directory > ADSync > Change the port on your Domain controllers to 636 (That’s LDAPS TCP Port 636, so it needs to be open on any firewalls between the Duo Auth Proxy, and the domain controllers!)

Go to Transport Type > Change to LDAPS > Paste in your CA Certs PEM information into the ‘SSL CA Certs’ Section > Save Directory.

Why didn’t you tick ‘SSL Verify Hostname’? Simply because it fails when I do that, I’m assuming the common name on the LDAPS cert on my domain controllers is the hostname of the DC, and not its FQDN, so I needed to leave this unticked.

All being well it should say connected.

Troubleshooting Duo LDAPS

Duo have a tool that will check your domain controller certificates are OK. It’s called acert.exe or you can enable debugging, or use the connectivity tool.

Related Articles, References, Credits, or External Links

NA

Cisco FirePOWER Management Center Appliance – Allowing Domain Authentication

Posted on by
Reply

KB ID 0001117 

Problem

Once deployed, authentication is handled by the appliances own internal user database, in larger organisations this is a little impractical. So the ability to create an Active Directory Group, and delegate access to Firesight to members of that group is a little more versatile.

Solution

I’m making the assumption that the appliance does not already have external authentication setup at all, so I’ll cover everything from start to finish.

Newer Versions

Logon to the Appliance > System >Users > External Authentication > Add External Authentication Object

Older Versions

Logon to the Appliance > System > Local User Management > External Authentication > Create External Authentication Object.

  • Authentication Method: LDAP
  • Name: Chose a sensible name for the connection.
  • Server Type: MS Active Directory
  • Host Name/IP Address: the IP of your domain controller
  • Port:389 (this is standard LDAP)

If you have a second Domain Controller enter the details here.

Note: In Active Directory, I’ve created a USER to make the connection to Active Directory with, and I’ve also created a SECURITY GROUP that my administrators will be in.

You can use the ldp.exe tool to locate and find the correct LDAP path for the user you created, (and the group because you will need that in a minute as well).

  • Base DN: Usually the root of the domain, in standard LDAP format.
  • Username: The LDAP path to the user you created.
  • Password: For the user above.
  • UI Access Attribute: sAMAccountName
  • Shell Access Attribute: sAMAccountName

I’m simply having one administrative group, if you have a granular RBAC requirement, there are a number of pre-configured roles you can assign your AD groups to, (or you can create custom ones). So I’m adding the LDAP path of my administrators group to the ‘Administrator’ role.

Also set the default role to ‘Security Analyst (Read Only).

  • Group Member Attribute: member.
  • Username: A user in the AD Administrative group you created.
  • Password: Password for the above account.

Press ‘Test’

All being well you should see a success, Press Save.

Newer Versions

Switch the ‘slider’ to enabled > Save > Save and Apply. (Now skip to All Systems below).

Older Versions

You now need to add this to the policy being applied to this appliance. System > Local System Policy > Select the policy in use  >Edit.

External Authentication

  • Status: Enabled
  • Default User Role: System Analyst (Read Only)

Finally change the slider button and ensure it is ticked. Save policy and exit.

Now apply the policy (green tick).

Tick the appliance > Apply.

Success.

All Systems

Now you can login with your administrative AD accounts.

You can also create a local user to match an AD account.

And get the appliance to use AD for authentication of this user.

Related Articles, References, Credits, or External Links

Original Article Written 18/12/15

Cisco AnyConnect – Allow Domain Password Change via LDAP

Posted on by
4

KB ID 0001273 

Problem

 

If you have remote users who connect via VPN, and a policy that forces them to change their password periodically, this can result in them getting locked out without the ability to change their password (externally).

If your Cisco ASA is using LDAP to authenticate your users, then you can use your remote AnyConnect VPN solution to let them reset their passwords remotely.

Solution

Standard LDAP runs over TCP port 389, to allow the ASA to reset the password for the users, it needs to be connected via LDAPS ((TCP Port 636). Your AD server needs to be able to authenticate via LDAPS, by default it will not. I’ve already covered how to set that up in another post see the following article.

Windows Server 2012 – Enable LDAPS

So, assuming your AD server(s) that the Cisco ASA is authenticating against is already setup, you need to ensure that your AAA Settings for LDAP is set to use port 636.

Enable LDAPS via Command Line

On my test network I only have one LDAP server in my LDAP AAA group, you may need to repeat this procedure for each one in yours.

[box]

Petes-ASA(config)# aaa-server TEST-LDAP-SERVER (inside) host 192.168.110.10
Petes-ASA(config-aaa-server-host)# server-port 636

[/box]

Enable LDAPS From within the ASDM

Log into the ADSM  > Configuration > Device Management > Users/AAA  > Select the LDAP Server Group > Select the Server > Edit > Enable LDAP over SSL > Server Port = 636.

Note: If you attempt to reset a user password without LDAPS, then you will see the following error;

Unwilling to perform password change

Next you need to edit the AnyConnect connection profile to allow password resets. Or the tunnel-group if you work at command line.

Allow Password Reset via Command Line

[box]

Petes-ASA(config)# tunnel-group ANYCONNECT-PROFILE general-attributes
Petes-ASA(config-tunnel-general)# password-management password-expire-in-days 3

[/box]

Allow Password Reset via ASDM

Connect to the ADSM > Configuration > Remote Access VPN > Network Client remote Access > AnyConnect Connection Profile > Select the one for AnyConnect > Edit > Advanced > General > Password Management > Enable Password Management > Select to notify user the amount of days before his/her password expires > OK > Apply > File > Save running configuration to flash.

Now your users have the ability to reset their password remotely as they are about to expire, and when they have expired.

If you want to test with a particular user you can set his password to ‘expired’ using the following procedure;

Reset an AD Users Password Expiry Date

Related Articles, References, Credits, or External Links

NA

AnyConnect – ‘Your environment does not meet the criteria’

Posted on by
2

KB ID 0001232 

Problem

For an existing client, I was setting up a new user. I connected their laptop though my mobile phone and attempted to connect. This is the error I got.

Cisco AnyConnect
Logon denied: Your environment does not meet the access criteria defined by your administrator.

Solution

A cursory glance over the firewall config didn’t yield anything in their AAA settings that was odd, they were simply using LDAP for authentication.

I probably should have guessed the answer earlier than I did, (because I’ve written an article on it). But the reason this was failing was, the firewall had a Dynamic Access Policy (DAP) attached to the remote VPN, that only permitted access to users that were in a particular Active Directory group. This user was not a member of that group.

To check your Dynamic Access Policies and understand how to find them, (you need to be in the ASDM!) See the following article;

Cisco ASA – AnyConnect Authentication via LDAP and Domain User Groups

Related Articles, References, Credits, or External Links

NA

Cisco – Testing AAA Authentication (Cisco ASA and IOS)

Posted on by
5

KB ID 0001175 

Problem

I always forget the syntax for this, and I’ve been meaning to publish this for a while so here you go. If you have AAA setup and people can’t log in, then the ability to test authentication against a user’s username and password is a good troubleshooting step!

Usually I’m on a Cisco ASA but I’ll tag on the syntax for IOS as well.

 

Solution

Cisco ASA Test AAA Authentication From Command Line

You will need to know the server group and the server you are going to query, below the ASA is using LDAP, but the process is the same for RADIUS, Kerberos, TACACS+, etc.

[box]

Petes-ASA# show run | begin aaa
aaa-server TEST-LDAP-SERVER protocol ldap
aaa-server TEST-LDAP-SERVER (inside) host 192.168.110.10
 ldap-base-dn dc=TEST,dc=net
 ldap-scope subtree
 ldap-naming-attribute sAMAccountName
 ldap-login-password *****
 ldap-login-dn cn=asa,OU=Users,OU=Test-Corp,dc=TEST,dc=net
 server-type auto-detect

[/box]

To test your user, (username: ttester password: Password123);

[box]

Petes-ASA# test aaa-server authentication TEST-LDAP-SERVER host 192.168.110.10 username ttester password Password123
INFO: Attempting Authentication test to IP address  (timeout: 12 seconds)
INFO: Authentication Successful

[/box]

Cisco ASA Test AAA Authentication From ASDM

Log into the ADSM  > Configuration > Device Management > Users/AAA  > Select the Server Group > Select the Server > Test.

Select ‘Authentication’ > Enter Username/Password > OK.

Cisco IOS Test AAA Authentication From Command Line

As above, you need to know which server group, and server, you are going to test authentication against;

[box]

Petes-Router#show run aaa
!
aaa authentication login default local
aaa authorization exec default local
!
aaa group server radius RADIUS-GROUP
 server-private 192.168.110.10 key 666999
!
aaa new-model
aaa session-id common
!

[/box]

Text

[box]

Petes-Router#test aaa group RADIUS-GROUP tester Password123 legacy
Attempting authentication test to server-group RADIUS-GROUP using radius
User was successfully authenticated.

OR

Petes-Router#test aaa group RADIUS-GROUP tester Password123 new-code
User successfully authenticated

USER ATTRIBUTES

Framed-Protocol 0 1 [PPP]
service-type 0 2 [Framed]
noescape 0 True
autocmd 0 " ppp negotiate"
Petes-Router#

[/box]

Related Articles, References, Credits, or External Links

Cisco ASA – AnyConnect Authentication via LDAP and Domain User Groups

Windows Server 2012 – Configure RADIUS for Cisco ASA 5500 Authentication

Windows Server 2008 R2 – Configure RADIUS for Cisco ASA 5500 Authentication

Cisco ASA 5500 Client VPN Access Via Kerberos (From CLI)

Set Cisco ASA for Kerberos Authentication

Cisco ASA – AnyConnect Authentication via LDAP and Domain User Groups

Posted on by
50

KB ID 0001152

Problem

When I first started doing Cisco remote VPNs, we had Server 2000/2003 and I used to use RADIUS with IAS. Then Microsoft brought out 2008/2012 and RADIUS via NAP. Because I fear and loath change I swapped to using Kerberos VPN Authentication for a while. I had to put in an ASA5512-X this weekend and the client wanted to allow AnyConnect to a particular Domain Security Group “VPN-Users”, so I thought I would use LDAP for a change.

The process is to setup AAA for LDAP, then create an ‘Attribute map’ for the domain group, and then map that group to a particular ASA Tunnel Group/ASA Group Policy. Though to be honest if you have multiple groups and want to assign different levels of access (i.e. different ACLs etc.) then using a blend of LDAP and Cisco Dynamic Access Policies (DAP) is a lot simpler.

I’ll post both options, and you can take your pick

Solution

Firstly you need to create a ‘service account’ in Active Directory that the ASA will use, it only need to be able to browse the AD, so a simple Domain User is fine.

Then create a user group that you want to grant AnyConnect Access to;

And, then create a test user and put that user in your domain group.

Configure the ASA for LDAP

Create an AAA LDAP Server Group > Add a Server > Put in the Config for that server like so;

[box]

CHANGE THE ENTRIES IN BOLD BELOW TO MATCH YOUR REQUIREMENTS

Type help or '?' for a list of available commands.
Petes-ASA> enable
Password: ********
Petes-ASA# configure terminal
Petes-ASA(config)# aaa-server PNL-LDAP-SERVER protocol ldap 
Petes-ASA(config-aaa-server-group)# aaa-server PNL-LDAP-SERVER (inside) host 192.168.100.10
Petes-ASA(config-aaa-server-host)# ldap-base-dn dc=pnl,dc=com     
Petes-ASA(config-aaa-server-host)# ldap-scope subtree 
Petes-ASA(config-aaa-server-host)# ldap-naming-attribute sAMAccountName
Petes-ASA(config-aaa-server-host)# ldap-login-password P@assword123
Petes-ASA(config-aaa-server-host)# ldap-login-dn cn=asa,OU=ServiceAccounts,OU=PNL,dc=pnl,dc=com
Petes-ASA(config-aaa-server-host)# server-type auto-detect 
Petes-ASA(config-aaa-server-host)# exit
Petes-ASA(config)# exit
Petes-ASA#

[/box]

Now perform a test, and make sure it says “successful’

[box]

NOTE: HERE I'VE SET IT TO FALL BACK TO LOCAL AUTH IF THE LDAP SERVER IS DOWN!
Petes-ASA# test aaa-server authentication PNL-LDAP-SERVER host 192.168.100.10 username 
administrator password P@ssword123
INFO: Attempting Authentication test to IP address  (timeout: 12 seconds)
INFO: Authentication Successful
[/box]

Add LDAP Authentication For AnyConnect

I’m assuming you already have AnyConnect Setup? If not that’s fine simply follow the article below, which will set it up for LOCAL authentication, set it up and get it working then come back here.

Cisco ASA 5500 AnyConnect Setup From Command Line

To change authentication from LOCAL you make a change in the Tunnel-Group for you remote VPN connection, if you don’t know what the name of your tunnel group is ‘show run tun’ will list them. You add the authentication-server-group to the general-attributes section of the config, like so;

[box]

NOTE: HERE IT WILL FAIL BACK TO 'LOCAL' AUTH IF LDAP GOES DOWN (THIS IS GOOD!)

Petes-ASA(config)# tunnel-group PNL-TG-ANYCONNECT-ACCESS general-attributes
Petes-ASA(config-tunnel-general)# authentication-server-group PNL-LDAP-SERVER LOCAL
Petes-ASA(config-tunnel-general)# exit
Petes-ASA(config)# write mem
Building configuration...
Cryptochecksum: 30899474 8c9cd7c6 495be299 fd911bca 

19681 bytes copied in 3.340 secs (6560 bytes/sec)
[OK]
Petes-ASA(config)#

[/box]

Note: At this point ALL DOMAIN USERS can successfully authenticate, to lock it down to one domain security group, either apply a Dynamic Access Policy (these can only be done in the ASDM). or skip further down, to edit and create your group-policies and use an attribute-map.

Cisco ASDM Configure Dynamic Access Policies

Connect to the ASDM > Configuration > Remote Access VPN > Dynamic Access Policies > Add.

Add an LDAP Condition > IF NOT a member (or not equal to member) > Insert domain security group. Then set the condition to ‘Terminate’.

Then test.

Configure Group Access via Attribute Map

As already pointed out I’m assuming you already have AnyConnect in and working, so you will have both a Group-Policy your users are using, and a tunnel-group configured, we will make some changes to those. if you don’t know thew name of your configured group-policy or tunnels group the following two commands will tell you;

  • To see your tunnel group(s): show run tun
  • To see your group-policy(s): show run group-policy

Note: If you have many, simply connect with a user, then run show vpn-sessiondb det anyconnect to get the details.

Firstly create a NEW group-policy that blocks access (this will become the default).

[box]

Petes-ASA(config)# group-policy ANYCONNECT-NO-ACCESS internal
Petes-ASA(config)# group-policy ANYCONNECT-NO-ACCESS attributes
Petes-ASA(config-group-policy)#  vpn-simultaneous-logins 0
Petes-ASA(config-group-policy)# exit

[/box]

Then we will change your EXISTING group-policy to change the simultaneous login threshold

[box]

Petes-ASA(config)# group-policy GroupPolicy_ANYCONNECT-PROFILE attributes
Petes-ASA(config-group-policy)#  vpn-simultaneous-logins 3
Petes-ASA(config-group-policy)# exit

[/box]

Then we will change your EXISTING tunnel-group to change the authentication method, and set the default group-policy to ‘deny’. Note: Ive added the ASA’s local user database as a fall-back in case the LDAP server(s) are down/not-contactable.

[box]

Petes-ASA(config)# tunnel-group ANYCONNECT-PROFILE general-attributes
Petes-ASA(config-tunnel-general)#  authentication-server-group PNL-LDAP-SERVER LOCAL
Petes-ASA(config-tunnel-general)#  default-group-policy ANYCONNECT-NO-ACCESS
Petes-ASA(config-tunnel-general)# exit

[/box]

Create an Attribute map, that matches the AD group that has your ‘allowed’ users in it.

[box]

Petes-ASA(config)# ldap attribute-map AM-ANYCONNECT-USERS
Petes-ASA(config-ldap-attribute-map)#   map-name  memberOf Group-Policy
Petes-ASA(config-ldap-attribute-map)#   map-value memberOf CN=VPN-Users,OU=Groups,OU=PNL,DC=pnl,DC=com GroupPolicy_ANYCONNECT-PROFILE
Petes-ASA(config-ldap-attribute-map)# exit

[/box]

Finally add that Attribute map, to the LDAP server you created earlier.

[box]

Petes-ASA(config)# aaa-server PNL-LDAP-SERVER (inside) host 192.168.100.10
Petes-ASA(config-aaa-server-host)#  ldap-attribute-map AM-ANYCONNECT-USERS

[/box]

Then test;

 

Related Articles, References, Credits, or External Links

Cisco AnyConnect – Allow Domain Password Change via LDAP

Thanks to Ben Monroe, who emailed me as the original article was lacking the Attribute Map section. I had omitted it originally and stuck with DAP, primarily because I could not get LDAP group authentication to work! I still prefer DAP as a solution, but for the sake of completeness I revisited this, and added the complete LDAP procedure.

Is Virtual Center 4.1 Supported on Windows Server 2008 R2?

Posted on by

KB ID 0000379 

Problem

ES! it is, if in doubt see the compatibility matrix. But you have tried to install it and seen an error?

Error: This product can only be installed on the following 64-bit operating systems: Windows XP SP2 or above Windows Server 2003 Windows Server 2008

Solution

Essentially this just a bad error message that bears no resemblance the the actual problem!

The REAL REASON you are seeing this error is because you re trying to install vCenter on a domain controller.

This happens because, as part of the vCenter 4.1 setup the following takes place,

And if the server is a Domain controller, AD LDS cannot be installed. You will notice that if you watch the “Roles” section during the install of vCenter, that a role drops onto the list.

Final Thoughts

For anyone who thinks “Well Ill put vCenter on first then make the server a domain controller”. That won’t work either, if you try that you will see this error,

Error: The TCP ports shown below are required by Active Directory Domain Services, but are already in use on this computer. 389 ldap

To be honest a more descriptive error message would help. (Cheers VMware!). It’s not as if you cant do it…

Same thing on Server 2008

Related Articles, References, Credits, or External Links

NA

Windows Server – Enable LDAPS

Posted on by

KB ID 0000962 

Problem

Active Directory is built on LDAP, I’ve known this for a long time, but other than it’s a directory protocol that’s about all I did know. Like any directory, if you want information when you query the directory it returns a result. The problem is that information is sent in ‘cleartext’, which is not ideal. To address that you can secure and encrypt that traffic with SSL.

The reason I’m concerned with LDAPS this week, well I was deploying, an RSA Authentication Manager Appliance and when I tried to add Active Directory as an Identity source, this happened;

RSA Operations Console

Add New Identity Source

There was a problem processing your request.
Test connection failed. One
or more directory connections is incorrect.

Solution

To query a domain controller over LDAPS you need a certificate to secure that communication, techies tend to back away when PKI is mentioned, I’m not sure why, but most people fear what they don’t understand, and encryption is pretty complicated,but just think;

  • PKI issues certificates to things.
  • The certificates make stuff work.
  • They expire and need to be renewed.

With that in mind, there are two ways for us to solve this problem. Option 1: Install an enterprise root CA on one of your domain controllers, (that fixes all these problems in one hit). If you only have one server that’s probably our best option, but in any production network thats not a very elegant solution. So Option 2: Is setup a domain PKI solution and use that.

If you already have a PKI/CA infrastructure great, if not, then simply pick a server and launch Server Manager > Manage > Add Roles and Features > Add in the Active Directory Certificate Services role > Follow the on screen prompts.

Actually setting up PKI is outside the scope of this article, I’m running with the assumption that you have a Root/Enterprise CA setup and ready to go.

 

1. On your CA Server launch the Certification Authority Management Console > Certificate Templates > Right Click > Manage.

2. Locate the Kerberos Authentication certificate > Make a Duplicate.

3. General Tab > Call it ‘LDAPoverSSL’ > Set its validity period > Decide if you want to publish the cert in AD.

4. Request Handling Tab > Select ‘Allow private key to be exported’ > Apply > OK.

5. Right click Certificate Templates again > Certificate Template to issue.

6. Locate and select the ‘LDAPoverSSL’ certificate > OK.

7. Now logon to a DOMAIN CONTROLLER > Windows Key+R > mmc {Enter} > File > Add/Remove Snap-in > Add in the Certificates Snap-In > Computer account > Finish > OK > Expand Certificates > Personal > Certificates > Right Click > All Tasks > Request New Certificate > Next > Next.

8. Select the LDAPoverSSL Certificate > Enroll > Close the Certificate Snap-in.

9. In my case I need my device to ‘Trust’ the CA, So on the CERTIFICATE SERVER > open a command window and run the following command;

[box]
certutil -ca.cert ca_name.cer
[/box]

10. It will display the certificate PEM on the screen and should complete successfully.

11. You will notice my command was run while I was on the root of the C: Drive, yours will probably be C:Users{your-username} go there and retrieve a copy of the ‘Root Certificate’.

Testing LDAP and LDAPS

12. On another server > Open a command windows and run ldp > Connection > Connect > Type in the FQDN of the DC > Set the port to 636 > Select SSL > OK > It should return some results

Note: If you get an error you may need to reboot the domain controller.

That’s your DC configured (You can repeat the process for further DC’s), but remember Imtrying to connect my RSA Appliance.

Adding Active Directory to RSA Authentication Manager

13. Log onto the Operations Console (https://{fqdn}/oc) Deployment Configuration > Identity Source Certificates > Add New > Add in the Root-Cert you exported above.

14. This time when I add my Active Directory as an Identity Source, it completes without error.

 

Related Articles, References, Credits, or External Links

NA

Cisco ASA – Allowing Domain Trusts, and Authentication

Posted on by

KB ID 0000973 

Problem

I cringed this morning when I was asked about this, last time I had to get a client to authenticate to a domain through a firewall, it was ‘entertaining’. The problem is Windows loves to use RPC, which likes to use random ports, so to make it work you either had to open TCP ports 49152 and 65535 (Yes I’m Serious). Or you had to registry hack all your domain controllers and specify individual ports for RPC as per MS KB 224196, then allow those ports. I have a client that’s got a separate domain in their DMZ and I need to setup a trust with their internal domain, so I started writing the firewall config. Then when I asked the ‘Do you want to open all these ports or simply lock RPC down on all the domain controllers?’ Question, my colleague found ‘dcerpc’ inspection.

Dcerpc has been available since at least ASA version 7.2, I had never heard of it! Cisco Says;

DCERPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.

DCERPC inspection maps inspection for native TCP communication between a server called the Endpoint Mapper (EPM) and client on the well-known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and port number are received from the applicable EPM response messages. Because a client can attempt multiple connections to the server port returned by EPM, creation of multiple pinholes is allowed

Heres how to do it with the following topology;

Note: Setting up a ‘Trust’ or allowing a client to ‘Authenticate’ requires the same configuration, but below I will use the IP of the Domain controller, rather than the IP of the client.

Solution

I’m assuming you ALREADY have access-lists from your internal network, and from your DMZ, you may need to replace the names of the ACL’s I use below with your own, ‘show run access-group’ will tell you.

1. There are a myriad of ports, (both TCP and UDP) that you are required to open, those being;

So connect to the ASA, Go to enable mode, then global configuration mode, and add the ACL’s to open the ports above. BE AWARE the last line enables ICMP/ping (just for testing you can remove it later and you will need to have ICMP inspection on for it to work).

[box]


Type help or '?' for a list of available commands.
PetesASA> enable
Password:**********
PetesASA# configure terminal
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 135
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 464
PetesASA(config)#access-list outbound permit udp host 192.168.1.10 host 172.16.1.10 eq 464
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 389
PetesASA(config)#access-list outbound permit udp host 192.168.1.10 host 172.16.1.10 eq 389
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 636
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 3268
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 3269
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 53
PetesASA(config)#access-list outbound permit udp host 192.168.1.10 host 172.16.1.10 eq 53
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 88
PetesASA(config)#access-list outbound permit udp host 192.168.1.10 host 172.16.1.10 eq 88
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 445
PetesASA(config)#access-list outbound permit icmp host 192.168.1.10 host 172.16.1.10

[/box]

2. Then we need to allow the traffic from the other direction, again here my ACL is called ‘DMZ’, check and change yours accordingly.

[box]PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 135
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 464
PetesASA(config)#access-list DMZ permit udp host 172.16.1.10 host 192.168.1.10 eq 464
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 389
PetesASA(config)#access-list DMZ permit udp host 172.16.1.10 host 192.168.1.10 eq 389
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 636
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 3268
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 3269
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 53
PetesASA(config)#access-list DMZ permit udp host 172.16.1.10 host 192.168.1.10 eq 53
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 88
PetesASA(config)#access-list DMZ permit udp host 172.16.1.10 host 192.168.1.10 eq 88
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 445
PetesASA(config)#access-list DMZ permit icmp host 172.16.1.10 host 192.168.1.10[/box]

3. Now create a class-map and set it to inspect TCP port 135.

[box]PetesASA(config)# class-map CM-DCERPC
PetesASA(config-cmap)# match port tcp eq 135[/box]

4. Then create a policy-map to use that class map to perform dcerpc inspection.

[box]PetesASA(config-cmap)# policy-map PM-DCERPC
PetesASA(config-pmap)# class CM-DCERPC
PetesASA(config-pmap-c)# inspect dcerpc
PetesASA(config-pmap-c)# exit [/box]

5. Finally apply the policy-map to the interfaces with a service-policy.

[box]PetesASA(config)# service-policy PM-DCERPC interface inside
PetesASA(config)# service-policy PM-DCERPC interface DMZ[/box]

6. Give it a test, make sure the machines can ping each other, and you may at this point want to remove the ICMP lines from the ACL. Once you are happy, save the changes.

[box]PetesASA# write mem
Building configuration…
Cryptochecksum: 4d7f7ccd 5c55a9e1 6ced12c4 46728bc7
[OK]
PetesASA#[/box]

 

Related Articles, References, Credits, or External Links

NA