Cisco MACSec Notes

2015.11.05

A while back I did notes for MACSec on Juniper devices and here’s the Cisco equivalent of the 802.1AE (“MAC Sec”) implementation

  1. Your Cisco device needs to be running either an IP Base or IP Services image. MACSec is not happening otherwise.
  2. switch# cts credentials id trustsec password mypassword
  3. en then, conf t, then int Gig1/1 (or whatever)
  4. switch(config-if)# cts man
    % Enabling macsec on Gi1/1 (may take a few seconds)…
    switch(config-if-cts-manual)#no propagate sgt
    switch(config-if-cts-manual)#sap pmk abc123 mode-list gcm-encrypt
    switch(config-if-cts-manual)#no shut

Where abc123 is your shared secret. I believe this is analogous to Juniper’s cak. You can do this to aggregated links (“port-channel” for you Cisco folks) but you have to do it before you aggregate the trunks together into a single logical interface. E.g., do this on Gig1/1 and Gig1/2 and then create int Port-channel1 (channel-group 1 mode on in the interface config)

Notes:

mode-list options are:

  • gcm-encrypt (authentication and encryption)
  • gmac (auth, no encrypt)
  • null (encapsulation only; no auth, no encryption)

 

Gotchas:

  • to use 802.1x (cts dot1x) as opposed to cts man above, you have to enable 802.1x globally on each device.
  • if you select gcm as the sap mode, you need an additional macsec license from cisco (as well as the ipbase or ipservices image/license). if you select gcm without the license, the interface goes into link-down state.

Debugging:

show cts credentials

show macsec summary

show macsec interface

show authentication sessions interface gigabitethernet1/1

 

Additional reading:

The actual Cisco doc (this is for a cat4500 but translates well most places) http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/15-1/XE_330SG/configuration/guide/config/swmacsec.html (here’s one for 3750/3560)

http://www.petenetlive.com/KB/Article/0001000.htm

http://www.virtualpackets.com/cisco-trustsec-switch-to-switch-link-security-manual-mode/

 

Linux user auth against Active Directory

2014.07.30

Enabling user authentication on linux against Active Directory, using ubuntu, sssd and AD 2008 (should work with 2003r2)
1. Install the software you need:

apt-get install realmd sssd samba-common samba-common-bin samba-libs sssd-tools krb5-user adcli

2. vi /etc/sssd/sssd.conf and put this in it:

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3

3. chmod 0600 /etc/sssd/sssd.conf

4. vi /etc/realmd.conf and put this in it:

[service]
 automatic-install = no

5. run kinit Administrator@YOURDOMAIN.ALLINCAPS.TLD
6. run realm –verbose join yourdomain.allincaps.tld \
–user-principal=ubuntuserverhostname/Administrator@YOURDOMAIN.ALLINCAPS.TLD –unattended

You should have more content inside sssd.conf now, in the [domain/YOURDOMAIN.ALLINCAPS.TLD] section.
7. vi /etc/sssd/sssd.conf and comment out the line use_fully_qualified_names = True

 

You should now be able to su – to a domain user.

That’s it, you’re done: you can login to your linux box by authenticating to your Active Directory domain.

Additional (and optional) stuff is below, like adding groups and restricting logins based on groups.

 

Additional settings inside /etc/sssd/sssd.conf [domain] section to enable groups:

 [domain/yourdomain.allincaps.tld]
 ad_domain = yourdomain.allincaps.tld
 krb5_realm = YOURDOMAIN.ALLINCAPS.TLD
 realmd_tags = manages-system joined-with-adcli
 cache_credentials = True
 id_provider = ad
 krb5_store_password_if_offline = True
 default_shell = /bin/bash
 ldap_id_mapping = True
## comment out
#use_fully_qualified_names = True
## these will need to be created manually or you will need to modify pam to 
## mkdir them with pam_mkhomedir.so or use oddjob-mkhomedir, see below
 override_homedir = /home/%u
 fallback_homedir = /home/%d/%u
##group settings##
 ldap_group_uuid = objectGUID
 ldap_user_uuid = objectGUID
 ldap_group_member = member
 ldap_user_member_of = memberOf
 ldap_user_uid_number = uidNumber
 ldap_group_nesting_level = 1
 ldap_force_upper_case_realm = True
 ldap_user_principal = userPrincipalName
 ldap_user_object_class = user
 ldap_user_gid_number = gidNumber
 ldap_group_modify_timestamp = whenChanged
 ldap_group_object_class = group
 ldap_group_name = cn
 ldap_user_name = sAMAccountName
 ldap_ns_account_lock = userAccountControl
 ldap_user_home_directory = unixHomeDirectory
 ldap_user_modify_timestamp = whenChanged
 ldap_group_gid_number = gidNumber
 ldap_referrals = false
 ldap_group_nesting_level = 0

Test that groups are working by su’ing to an AD user and typing in “groups”, which will show you what groups your user is a member of.

To make the homedirectory autocreate:

1. edit /etc/pam.d/common-session (/etc/pam.d/session-auth in RHEL)and add this line before any pam_ldap or pam_krb5 lines:

#autocreate user homedirs
 session required pam_mkhomedir.so umask=0022 skel=/etc/skel

To limit login by AD group:

  1. Create a file that will have the group names allowed to login:
    vi /etc/login.allowed.per.ad.group

    and populate it with group names, one per line (I created an AD group called linux-login, to limit which users were allowed to login), like so:

    root
    wheel
    domain\ admins
    linux-login
  2. edit /etc/pam.d/common-auth (in RHEL this is /etc/pam.d/system-auth) and add this line to it:
    auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/login.allowed.per.ad.group

 

To allow an AD group to have access to sudo:

  1. visudo
  2. add the AD groups

%domain\ admins ALL=(ALL) ALL

%linux-sudo ALL=(ALL) ALL

Further reading:
Allow/Deny login per group:
http://www.cyberciti.biz/tips/howto-deny-allow-linux-user-group-login.html

Various bits, mostly to do with LDAP authentication, but can be translated for use with AD/sssd/pam (e.g. homedir creation)
https://help.ubuntu.com/community/LDAPClientAuthentication

http://www.chriscowley.me.uk/blog/2014/06/17/new-linux-active-directory-integration/

http://funwithlinux.net/2014/04/join-ubuntu-14-04-to-active-directory-domain-using-realmd/

http://linux.tvortex.net/2011/10/sssd-against-active-directory-2003.html

https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server

Domain Authentication against AD for Cisco and Juniper network devices

2014.07.29

On the AD side:

  1. Install NPS on your AD DC.
  2. Create a key (http://dice.neko-san.net/2012/08/linking-junos-authentication-to-active-directory-using-radius/ has screenshots, if you need that sort of thing.)
  3. add clients (your switches/firewalls)

See also http://blog.arwin.me/os/cisco/how-to-setup-cisco-ios-to-authenticate-via-active-directory/

On a Cisco ASA:

aaa-server RADIUS protocol radius
aaa-server RADIUS host [IP address of your RADIUS box / AD machine running NPS] key [key]
radius-common-pw [key]
aaa authentication telnet console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication https console RADIUS LOCAL
aaa authentication http console RADIUS LOCAL

On a Cisco switch:

This example shows local authentication, which lets you Telnet into the router with username “cisco” and password “cisco.”

aaa new-model
username cisco password 0 cisco
line vty 0 4
transport input telnet

In order to test authentication with SSH, you have to add to the previous statements in order to enable SSH.

ip domain-name host.domain.tld
crypto key generate rsa
ip ssh time-out 60
ip ssh authentication-retries 2

If you want to prevent non-SSH connections, add the transport input ssh command under the lines to limit the router to SSH connections only.

line vty 0 4
transport input ssh
cry key gen rsa
ip ssh time-out 30
ip ssh version 2
line vty 0 4
transport input ssh

 

On a Juniper switch or firewall running JunOS:

set system authentication-order [radius password]
set system radius-server [IP Address of DC running NPS] secret [key]
set system radius-server [IP Address of DC running NPS] source-address [IP Address of interface that will communicate to DC]
set system radius-options password-protocol mschap-v2
set system login user [username] full-name "[Full User Name]" uid 9999 class super-user
# NOTE this erases your local password, so that ONLY the Domain password is allowed. This is more secure but more of a PITA if your NPS box craps out.
delete system login user [username] authentication encrypted-password