{"id":437,"date":"2021-02-27T16:34:19","date_gmt":"2021-02-27T15:34:19","guid":{"rendered":"http:\/\/www.labtinker.net\/?p=437"},"modified":"2021-02-27T16:34:19","modified_gmt":"2021-02-27T15:34:19","slug":"smashing-in-saml","status":"publish","type":"post","link":"http:\/\/18.135.13.153\/?p=437","title":{"rendered":"Smashing in SAML"},"content":{"rendered":"\n

My aim in this post is to get administrator access to a Palo Alto firewall using SAML authentication. The theory of this proccess is well-documented. Here is a explanation of it from Palo themselves:<\/p>\n\n\n\n

https:\/\/knowledgebase.paloaltonetworks.com\/KCSArticleDetail?id=kA10g000000ClVvCAK<\/a><\/p>\n\n\n\n

In summary, SAML allows federated authentication: basically we have a service provider (SP) and an identity provider (IdP) who trust each other. So when a user tries to authenticate to the SP, they are redirected to the IdP where the user has an account. The user inputs their credentials to prove this, and is then rewarded with a SAML assertion which the user then presents to the SP. As the SP trusts the IdP, it consumes the assertion and allows the user the appropriate access using the contents of the assertion.<\/p>\n\n\n\n

Our lab looks something like this (None of annoying infrastrucure an enterprise would have such as firewalls, proxies, load-balancers etc)<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In the rectangle we have two AWS Windows 2016 servers. The AD server is the PDC for the Active Directory domain. On the server <\/em>fs.labtinker.net <\/strong> we have ADFS (Active Directory Federation Service) installed or will have; and vpn.badtinker.net<\/strong> is a Palo Alto firewall spun up in Azure (bundle2) . My domains badtinker.net and <\/strong>labtinker.net are both in AWS Route 53 so DNS changes are easy enough.<\/p>\n\n\n\n

ADFS Installation<\/strong><\/p>\n\n\n\n

So I joined fs.labtinker.net <\/strong>to the labtinker.net AD domain and then installed ADFS as below:<\/p>\n\n\n\n

\"\"
Install Page 1<\/figcaption><\/figure>\n\n\n\n

Oh… I had to get hold of a certificate and install this on this box before I could select it, so I had added this this in my local machine store:<\/p>\n\n\n\n

\"\"
The ADFS server certificate<\/figcaption><\/figure>\n\n\n\n
\"\"
Install Page 2<\/figcaption><\/figure>\n\n\n\n

We specify a service account then create a database.<\/p>\n\n\n\n

\"\"
Install Page 3<\/figcaption><\/figure>\n\n\n\n

This process should create an SPN and we can confirm that with the following command (after logging into a domain account):<\/p>\n\n\n\n

\"\"
SPN in place.<\/figcaption><\/figure>\n\n\n\n

AD<\/strong> Server Config<\/strong><\/p>\n\n\n\n

There’s not much we need to do on the AD server itself apart from add a user. In this example I’m using John which I have already added.<\/p>\n\n\n\n

Palo Alto<\/strong><\/p>\n\n\n\n

On the Palo Alto we will need to define a SAML IdP. The easiest way to do this is to import the metadata from the ADFS server. As long as we have our DNS entry set up for fs.labtinker.net<\/strong> <\/em>this can be imported from the URL you find in AD FS Endpoints.<\/p>\n\n\n\n

\"\"
ADFS Endponts<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

\"\"
Metadata URL<\/figcaption><\/figure>\n\n\n\n

Namely:<\/p>\n\n\n\n

https:\/\/fs.labtinker.net\/FederationMetadata\/2007-06\/FederationMetadata.xml<\/a><\/p>\n\n\n\n

You will be able to browse to this and save an XML (not when you’re reading this as I’ll have shut down the lab – those cloud fees rack up.)<\/p>\n\n\n\n

\"\"
Grab the metadata file.<\/figcaption><\/figure>\n\n\n\n

Put that to one side and log into your Palo Alto – we will also need to add a DNS entry for vpn.badtinker.net <\/strong>and also import a certificate of the same name into the Palo’s cert store.<\/p>\n\n\n\n

Add SAML Identity Provider<\/strong><\/p>\n\n\n\n

On the Palo Alto’s device menu, we pop down to the SAML Identity Provider Screen:<\/p>\n\n\n\n

\"\"
SAML IdP on the Palo<\/figcaption><\/figure>\n\n\n\n

We have an ‘Import’ action and we name our IdP server and then browse to the ADFS metadata file. For my lab, I unticked the ‘Validate Identity Provider Certificate’ and increased the clock skew.. the latter I think unecessary but was a hangover from some troubleshooting, the former is necessary as we would need our IdP signing cert to be issued by a CA and it’s not – see below.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Having done this you’ll get a server entry and if you click on this you’ll see what’s in the metadata…<\/p>\n\n\n\n

\"\"
ADFS Server definition – notice I bumped up the clock skew when troubleshooting.<\/figcaption><\/figure>\n\n\n\n

Notice the IdP cert is crt.labtinker.shared.<\/strong> This is a self-signed cert our ADFS created and included in metadata so we should find it in the Palo’s cert store as indeed we do.<\/p>\n\n\n\n

\"\"
Signing Cert in the Palo’s Certificates Store.<\/figcaption><\/figure>\n\n\n\n

As this is a self-signed certificate, if we’d have checked ‘Validate Identity Provider Certifcate’, the Palo would try and check this online and find it couldn’t. There are ways to configure the ADFS server to use a CA-issued certificate but we haven’t here. <\/p>\n\n\n\n

OK, now we need to create an Authentication Profile which again is on the Palo’s device menu.<\/p>\n\n\n\n

\"\"
Authentication Profile<\/figcaption><\/figure>\n\n\n\n

We name it ‘saml’, or I did, specify the Type as ‘SAML’ and for the IdP Server profile select the certificate vpn.labtinker.net <\/strong>(installed earlier – with its private key – the public key of this will be included in the metadata we generated for the ADFS). We’ll keep the attribute we are using as username<\/em> so this is what we’ll expect to see in the SAML assertion from the ADFS.<\/p>\n\n\n\n

\"\"
Add an authentication profile.<\/figcaption><\/figure>\n\n\n\n

The ‘Advanced’ tab allows us to restrict this to given users, we’ll just add ‘any’.<\/p>\n\n\n\n

\"\"
All wecome.<\/figcaption><\/figure>\n\n\n\n

Having done this you’ll see the following…<\/p>\n\n\n\n

\"\"
SAML authentication profile<\/figcaption><\/figure>\n\n\n\n

You’ll notice there’s a metadata link here which will provide the metadata file we need to provide to the ADFS. Clicking on this, we need to fill in a couple of things. The service will be ‘managment’, the authentication profile is ‘saml’ and the ip or hostname is https:\/\/vpn.badtinker.net.<\/strong><\/p>\n\n\n\n

\"\"
Palo SAML Metadata export.<\/figcaption><\/figure>\n\n\n\n

OK – save this file away – we’ll need it back on our ADFS server.<\/p>\n\n\n\n

We need to do one more thing on the Palo and add a SAML admininstrator with the username that we’ll present in our assertion and map this to our ‘saml’ authentication profile. <\/p>\n\n\n\n

\"\"
John – SAML administrator.<\/figcaption><\/figure>\n\n\n\n

Back on the ADFS server…<\/strong><\/p>\n\n\n\n

We need to tell the ADFS server about the Palo by adding it as a Relying Party in the AD FS Tool.<\/p>\n\n\n\n

\"\"
Relying Party Trust Menu<\/figcaption><\/figure>\n\n\n\n

Clicking on the ‘Add Relying Party Trust’ sends us into a wizard.<\/p>\n\n\n\n

\"\"
Relying Party Trusts Options.<\/figcaption><\/figure>\n\n\n\n
\"\"
Add a trust<\/figcaption><\/figure>\n\n\n\n

We then are given a chance to import the Palo’s metadata.<\/p>\n\n\n\n

\"\"
Import the Palo’s metadata<\/figcaption><\/figure>\n\n\n\n

Here I input the metadata file I generated on the Palo then allowed all access to finish off.<\/p>\n\n\n\n

The relying party I named ‘Palo’ has the URL and public cert of the Palo in it…<\/p>\n\n\n\n

\"\"
Who’s relying on us?<\/figcaption><\/figure>\n\n\n\n
\"\"
What’s their public signature?<\/figcaption><\/figure>\n\n\n\n

OK, we’re not quite done. We need to tell the ADFS server what claims to send. We can stuff our assertion with no end of them but on this occasion we just want username so… we click on add ‘Claims Issuance Policy’<\/p>\n\n\n\n

\"\"
LDAP Attribute<\/figcaption><\/figure>\n\n\n\n
\"\"
Getting assertive.<\/figcaption><\/figure>\n\n\n\n

So this is what we send to the Palo. Now there’s one more thing I had to do to get this working and it you’re troubleshooting in a none-Production environment this may be worth doing anyway.<\/p>\n\n\n\n

I ran the following command on the ADFS server where ‘Palo’ was the name of the relying party.<\/p>\n\n\n\n

set-ADFSRelyingPartyTrust \u2013TargetName Palo \u2013EncryptClaims $False<\/em><\/p>\n\n\n\n

As you might gather this means that the assertions that the ADFS sends to the Palo are not encrypted with the Palo’s public key of the vpn.badtinker.net <\/strong>certificate. You can still seem these claims if they are encrypted (if you have the private key) by using an online tool but this exposes the key to a third party. I will perhaps go into this a little deeper in subsquent post. <\/p>\n\n\n\n

Anyway, let’s give this a try. We’ll browse to the Palo’s GUI on <\/p>\n\n\n\n

\"\"
The Palo’s front door.<\/figcaption><\/figure>\n\n\n\n

Choose ‘Use Single Sign-On’ and then input the SAML Administrator we created earlier (it’s case sensitive):<\/p>\n\n\n\n

\"\"
Who goes there?<\/figcaption><\/figure>\n\n\n\n

This will re-direct us to our ADFS server on https:\/\/fs.labtinker.net<\/strong><\/p>\n\n\n\n

\"\"
Re-direct to the ADFS<\/figcaption><\/figure>\n\n\n\n

and here we sign in using our labtinker domain account:<\/p>\n\n\n\n

\"\"
Authenticate to the domain.<\/figcaption><\/figure>\n\n\n\n

On a successful authentication this will re-direct back to Palo with the correct assertion.<\/p>\n\n\n\n

\"\"
SAML authenticated Admin session<\/figcaption><\/figure>\n\n\n\n
\"\"
System logs on the Palo.<\/figcaption><\/figure>\n\n\n\n

Next post I’ll dig a little bit more into what’s going on and demonstrate a couple of SAML tools.<\/p>\n","protected":false},"excerpt":{"rendered":"

My aim in this post is to get administrator access to a Palo Alto firewall using SAML authentication. The theory of this proccess is well-documented. Here is a explanation of it from Palo themselves: https:\/\/knowledgebase.paloaltonetworks.com\/KCSArticleDetail?id=kA10g000000ClVvCAK In summary, SAML allows federated authentication: basically we have a service provider (SP) and an identity provider (IdP) who trust […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-437","post","type-post","status-publish","format-standard","hentry","category-authentication"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts\/437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=437"}],"version-history":[{"count":0,"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts\/437\/revisions"}],"wp:attachment":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=437"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}