Slides for the October 2018 Netgate Hangout video

1. Using Google Cloud Identity
Secure LDAP with pfSense
October 2018 Hangout
Jim Pingle

2. Youtube Live
If the video looks fuzzy, Youtube
set the auto quality too low
Click the gear and choose 720p!

3. About this Hangout
●
Netgate News
●
What is LDAP?
●
Google Cloud Secure LDAP
●
Example Use Cases
●
Security Concerns
●
Setup on Google Cloud
●
Setup pfSense CE/pfSense 2.4.4
●
Setup Factory 2.4.4-p1 or later
●
Create Groups on pfSense
●
Testing Authentication
●
Using LDAP for pfSense
Administrative Logins
●
Other Uses
Google Partner Manager McCall McIntyre is in the audience today (Say hi!)

4. Netgate News
●
TNSR now available on Netgate Appliances
– https://www.netgate.com/press-releases/tnsr-now-available-on-netgate-appliances.html
– Netgate SG-5100, XG-1537, and XG-1541 for now, more models in the future
●
pfSense 2.4.4-RELEASE is out!
– If you have not upgraded yet, carefully read the release blog post, release notes, and upgrade guide
●
https://www.netgate.com/blog/pfsense-2-4-4-release-now-available.html
●
https://www.netgate.com/docs/pfsense/releases/2-4-4-new-features-and-changes.html
●
https://www.netgate.com/docs/pfsense/install/upgrade-guide.html
– Do not attempt to upgrade existing packages or install new packages on older releases before upgrading to pfSense
2.4.4
●
SG-5100 shipping now!
●
SG-1000 is now End of Sale
– Still supported, but no new device sales
– New device coming soon to take its place, details coming!
●
pfSense 2.3.x has reached its End of Life
– https://www.netgate.com/blog/pfsense-release-2-3-x-eol-reminder.html

5. Netgate News
●
Netgate Dual-Ethernet MinnowBoard Turbot device offers
– MBT-4220 price lowered to $299
– MBT-2220 and MBT-4220 now have an optional “black flame” laser etching add-on
– MBT devices now ship with a credit card sized USB key pre-loaded with pfSense
(use in bottom USB port)
– https://www.netgate.com/blog/netgate-dual-ethernet-minnowBoard-turbot-with-pfse
nse-special-offer.html
●
Linux Foundation Networking survey of Communication Service Providers
– https://www.netgate.com/blog/csps-ready-to-steamroll-open-source-networking.html
– https://www.lightreading.com/nfv/nfv-specs-open-source/the-reality-of-open-network
ing-in-csp-transformation-/a/d-id/746620
●
Jim Thompson spoke at the Embedded Linux Conference earlier this week,
his talk was about the technologies behind TNSR and how it is changing the
high-end router market

6. What is LDAP?
●
Lightweight Directory Access Protocol
●
Used for a variety of reasons, such as
– Central Authentication & Authorization
●
VPN, computer/network/server logins, IMAP/POP3, web applications, appliances, etc
– Organization directory (e.g. e-mail contacts)
– Store data about people/groups/units/entities
●
Implemented in a variety of ways, and used or provided by several directory service offerings, such as:
– OpenLDAP
– Google Cloud Identity (now)
– Microsoft Active Directory
– Apple Open Directory
– Novell eDirectory
●
Covered previously in other hangouts, the book, etc.
– https://www.netgate.com/resources/videos/radius-and-ldap-on-pfsense-24.html

7. Google Cloud Secure LDAP
●
Secure LDAP service that ties back to Google Cloud Identity
●
Can be used for authenticating cloud-hosted or on-premises applications and services
●
Companies that have already offloaded e-mail and drive storage to Google can now also use the
service for LDAP-based central auth
– No need to maintain separate authentication infrastructures and accounts locally and on Google services
●
Easy-to-use account management where users can maintain their own passwords
●
Currently rolling out to Cloud Identity and G Suite Enterprise customers over the next few weeks
●
https://cloud.google.com/blog/products/identity-security/simplifying-identity-and-access-manageme
nt-for-more-businesses
●
https://cloud.google.com/identity/
●
The setup described in this Hangout is also covered in the online pfSense docs
– https://www.netgate.com/docs/pfsense/usermanager/google-gsuite-auth-source.html

8. Example Use Cases
●
A company with multiple locations that uses G Suite Enterprise for
e-mail and storage that does not want to run a local LDAP server,
but still wants to take advantage of central authentication for
firewalls at all locations
●
A company that wants to use central authentication for VPNs, taking
advantage of the accounts already setup in Cloud Identity
●
Any other similar cases where using the hosted service has less
overhead and management than maintaining a local service

9. Security Concerns
●
Similar concerns to any hosted services or centrally located services across multiple locations in an organization
●
The classic tradeoff here is ease of management vs loss of control
●
Since the service itself is not controlled locally, there is some level of trust / risk involved
– Do you trust Google to handle this task?
– If you are using Cloud Identity / G Suite, odds are that is already something your org has decided!
●
Service is contingent on an active Internet connection and the service being up
– pfSense will fall back to local authentication in this case when used for web interface logins
– When used across multiple locations, the same connectivity concern applies there as well
– Primary factor there is reliability of the ISP or availability of redundant connectivity, which is not directly related to Google or
this service specifically
– Service availability concerns are low, as Google has a good track record of reliability
●
This does not open a channel through which Google can reach into your firewall or other devices
– Communication is initiated one way: The device queries the LDAP server, the LDAP server responds with results of query

10. Setup on Google Cloud
●
Currently requires an account using the "Cloud Premium" or "G Suite Enterprise" tier
●
Follow Google’s setup document at
https://support.google.com/cloudidentity/answer/9048516
– This must be followed exactly
– Not shown here because it varies by org and Google’s docs cover it thoroughly
●
Download the certificate and its key for use by pfSense
●
During the setup process, generate access credentials (username and password) to be used
for bind credentials
– https://support.google.com/cloudidentity/answer/9048541#generate-access-codes
●
Create any required groups and add members to these groups
– Note the exact names used as you will need to make groups with the same name on pfSense later!

11. Setup on pfSense
●
First step is to import the certificate
– Open the certificate files from Google in a text editor (Notepad, Notepad++, UE, etc)
– Navigate to System > Cert manager, Certificates tab
– Click Add/Sign to display the certificate import interface
– Change Method to Import an existing certificate
– Enter a Descriptive name, such as Google Cloud LDAP Client
– Copy and paste the contents of the downloaded certificate into the Certificate data box
– Copy and paste the contents of the downloaded key into the Private Key data box
– Click Save
●
Next steps depend on pfSense version (CE or Factory 2.4.4-p1)

12. Setup stunnel for CE or pfSense 2.4.4
●
On pfSense CE, and even on factory 2.4.4 and earlier, the LDAP client on the
firewall does not directly support an SSL client certificate, only a server certificate
●
The stunnel package works around this, setting up an encrypted tunnel to Google
Cloud Secure LDAP that can use the client certificate imported in the previous step
●
This requires stunnel package version 5.37, update the package if it’s already
installed on pfSense 2.4.4 but out of date
●
If not already on pfSense 2.4.4, upgrade to pfSense 2.4.4
●
If the stunnel package is not installed, install it from System > Package Manager,
Available Packages tab

13. Setup stunnel for CE or pfSense 2.4.4
●
Next, configure stunnel to connect to Google Cloud Secure LDAP
●
Navigate to Services > STunnel
●
Click Add to create a new profile
●
Enter a Description for this connection, such as Google Cloud Secure LDAP
●
Check Client Mode
●
Set Listen on IP to 127.0.0.1
●
Set Listen on port to 1636
●
Set the Certificate to the entry imported previously, in this case Google Cloud LDAP Client
●
Set Redirects to IP to ldap.google.com
●
Set Redirects to port to 636
●
Click Save

14. Setup LDAP for CE or pfSense 2.4.4 (stunnel)
●
This scenario is for CE or Factory 2.4.4 using stunnel
●
Select System > User manager, Authentication servers tab
●
Click Add to create a new entry
●
Enter a Descriptive name for this LDAP server, such as Google Cloud Secure LDAP
●
Set Type to LDAP
●
Set the Hostname or IP address to 127.0.0.1 so pfSense will connect through stunnel
●
Set Port value to 1636
●
Set Transport to TCP-Standard
– Since stunnel handles the encryption, this step uses plain TCP only, but since it only goes to localhost there is no danger
●
Set Protocol version to 3
●
Set Server timeout to 25
●
Set Search scope to Entire tree

15. Setup LDAP for Factory 2.4.4-p1 or later
●
This scenario is for Factory 2.4.4-p1 or later using built-in LDAP Client certificate support
●
Select System > User manager, Authentication servers tab
●
Click Add to create a new entry
●
Enter a Descriptive name for this LDAP server, such as Google Cloud Secure LDAP
●
Set Type to LDAP
●
Set the Hostname or IP address to ldap.google.com
●
Set Port value to 636
●
Set Transport to SSL - Encrypted
●
Set Peer Certificate Authority to Global Root CA List
●
Set Client Certificate to the entry imported previously, in this case Google Cloud LDAP Client
●
Set Protocol version to 3
●
Set Server timeout to 25
●
Set Search scope to Entire tree

16. Common LDAP Server Entries
●
These settings are unique to your domain/account, the example shown in the hangout (pfsense.org) or
the docs (example.com) is shown only as a demonstration and must be replaced with the actual domain
name and equivalent components!
– Set Base DN to the domain name in DN format
●
Ex: dc=example,dc=com
– Set Authentication containers to the Base DN prepended by the Users organizational unit
●
Ex: ou=Users,dc=example,dc=com
– Uncheck Bind anonymous to show Bind Credentials
– Set Bind credentials to the Secure LDAP username and password that were created on Google Cloud earlier
●
Set User naming attribute to uid
●
Set Group naming attribute to cn
●
Set Group member attribute to memberOf
●
Click Save

17. Create Groups on pfSense
●
When using LDAP auth for the pfSense WebGUI, permissions are
mapped to users and groups based on the values returned from LDAP
and entries that exist locally
●
If an LDAP user is a member of a group and that group exists on
pfSense with an identical name, then the user will have the privileges
assigned to that group
– Similarly, if an LDAP username matches a local user, the privileges of that user
also apply
●
Earlier, you made groups on Google Cloud and added members, now we
need to create matching entries on pfSense

18. Create Groups on pfSense
●
Create the group on pfSense
– Navigate to System > User Manager, Groups tab
– Click Add to make a new group entry
– Enter the Group name (Ex: fwadmins)
– Set the Scope to Remote
– Enter a Description, Remote Firewall Administrators
– Click Save
●
Edit the group again to add privileges
– Click the pencil icon on the row for the newly created group
– Click Add in the Assigned Privileges section
– Select the desired permissions for the group, for example: WebCfg - All pages
●
Do not select every item in this list! That will also select User - Config: Deny Config Write which prevents users from making
changes to the configuration
– Click Save to store the privileges

19. Testing LDAP Authentication
●
Test from Diagnostics > Authentication
●
Select the Google Cloud Secure LDAP server from the list and enter valid credentials, then click test
●
If auth was successful, it should also list any groups the user is a member of which also were found
locally on pfSense
– If auth worked but no groups were found, ensure that the name of the group matches on Google Cloud and on
pfSense, and ensure the user is a member of the group in the settings for the account on Google Cloud
●
If the authentication failed, check the main system log for errors and review every step in this
hangout and the online docs again
●
May need 16/11 from console/ssh after SSL changes to clear the LDAP environment settings
●
Only use the username is checked, anything after the @ is ignored when entered
– For example, joe@example.com will auth the same as joe@movie.edu
– The domain is ignored, only the username is taken and authenticated inside of the configured LDAP containers

20. Use LDAP For pfSense Administration Logins
●
Assuming authentication was successful and showed the correct groups, the server can now be
used for authenticating users on pfSense!
– Note that currently this only works for the GUI, and not SSH
●
To change pfSense so it uses Google Cloud Secure LDAP for firewall authentication…
– Navigate to System > User manager, Settings tab
– Set the Authentication server to Google Cloud Secure LDAP
– Click Save
●
After completing those steps, log out and then back in using a Google account for your organization
●
If the account fails, see the previous troubleshooting steps
●
When LDAP authentication fails, local authentication is tried
– A local account such as the default admin user can be used to get back in and adjust settings as needed if the
LDAP server is failing authentication or unreachable

21. Alternate Uses
●
Use directly for VPN auth if all users have access
– Users still need certs for SSL/TLS auth in OpenVPN
– Can use auth without certs if needed (easier, but less secure)
●
Add another LDAP server entry using extended filter so that it
can only auth a single group, e.g. VPNusers, then use that
server for OpenVPN/IPsec
●
Central Captive Portal auth source for the entire company

22. Conclusion
●
Questions?
●
Additional Resources for LDAP and Privileges:
– https://www.netgate.com/resources/videos/radius-and-ldap-on-pfsens
e-24.html
– https://www.netgate.com/resources/videos/user-management-and-pri
vileges-on-pfsense-24.html
– https://www.netgate.com/docs/pfsense/book/usermanager/index.html
●
Ideas for hangout topics? Post on forum, Reddit, etc