IWA w Kerberos (not using QAS) Continuation as new Qstn

[shoin]

@PaulHomes

Per your instructions.  I visited your blog (https://platformadmin.com/blogs/paul/2015/01/iwa-sas-94m2-linux/) that had all 1-15 steps listed and the links given in there for the first 1-7 then 12-15 (mid tier).  That is greatly appreciated (my joy stemmed from the practical steps given).  

I could not find steps 8-11.

Particularly this step: Configured the SAS Metadata Server for IWA, with a SAS service account and keytab

The other SAS Desktop and workspace server side changes in properties (steps in config and security guide), but need a little more detail on 'how' or where I could find that info.

Thank you in advance,

Cheers,

Shoin

[shoin]

+ if SAS is deployed on multi-machine for example meta, mid on one and compute on other, will these steps occur on both nodes (confirming)

[PaulHomes]

That will depend on your IWA requirements and the architecture you have. Configuring IWA / Kerberos across the board will be neater and provide more seamless access for your users, but there are partial configuration options too (e.g. IWA to metadata, SAS Token Authentication to compute etc). Unless there are good reasons not to I would look at configuring IWA widely for metadata, compute tier, and mid-tier applications (and possibly data sources). When it comes to mid-tier applications you also have the option for fallback configuration so that if IWA is not available it can fallback to credential prompting.

[PaulHomes]

It seems like steps 8-11 slipped through the cracks and I never got to posting those. It'll take me a while to write up my notes into a blog post and, given I have lots of customer work which naturally has a higher priority, I can't see me getting to it anytime soon. However, in the time since I wrote that post there's now lots of other resources which will help you. One of the ones that may help you the most is SAS Global Forum 2016 Paper SAS3443-2016 Kerberos Delegation with SAS® 9.4 by Stuart Rogers. Most of the keytab management commands and environment variable settings you'll need are in there along with lots of other very useful info.

If you haven't already seen it all of my other IWA blog posts are listed under the IWA tag: https://platformadmin.com/blogs/paul/tag/iwa/

Some specific ones I'll call out:

• SAS & IWA: Check the Logs: https://platformadmin.com/blogs/paul/2012/06/sas-and-iwa-check-the-logs/
  Always check the logs (metadata, object spawner) to make sure the connections you think are IWA are indeed IWA Kerberos and not using SAS token, cached credentials, NTLM etc.
• SAS & IWA: Host Name Aliases and SPNs: https://platformadmin.com/blogs/paul/2012/04/sas-and-iwa-host-name-aliases-spns/
  SAS & IWA: Reviewing SPNs: https://platformadmin.com/blogs/paul/2012/04/sas-and-iwa-reviewing-spns/
  If you are using host name DNS aliases and not the physical host name then you will need to ensure all required SPNs are registered in AD
• SAS and IWA: Two Hops: https://platformadmin.com/blogs/paul/2012/01/sas-and-iwa-two-hops/
  SAS & IWA: Verifying Trusted for Delegation Status: https://platformadmin.com/blogs/paul/2012/03/sas-and-iwa-verify-trusted-for-delegation/
  If you want to use IWA to a workspace server, and are not using SAS Token Authentication, then you'll need to get your domain admins to mark the servers as Trusted for Delegation.

Another document to read is, of course, the How to Configure Integrated Windows Authentication section of SAS® 9.4 Intelligence Platform: Security Administration Guide.

I wholeheartedly recommend building up the config methodically from the metadata server, to compute tier, to mid-tier, carefully verifying each step along the way (e.g. checking the logs) before moving on to the next steps. Trying to do everything in one go will be harder to troubleshoot.

See how you go with those resources. If you have any specific questions post them and I'll try to answer them if they can be done in a few minutes (and others here may be able to help too). If you need anything more in-depth, then it's probably best to get help from SAS Professional Services or a local SAS Partner. Setting this up across the board can be quite challenging and time-consuming (albeit very rewarding) - getting professional help from people that have done it before will be very cost effective.

[shoin]

Thank you for your time and details.  I appreciate it!

One question, so far.  The service class by default (for the IOM servers) is SAS.  Is it related with the actual ID?  For example, if the installing ID is sasinst for example, will the service class default name still be SAS or it ought to match the ID?

Thank you in advance,

Shoin

[PaulHomes]

If I understand your question correctly and you are asking about the prefix on the Service Principal Name (SPN) then it is just static text "SAS/" and the name is not based on the service account name (all though it is associated with the service account). I've never tried to use anything other than SAS/ so not sure if there is any SAS option to change it. When I create my service account for SAS in AD I use the following details:

In the AD Computers container create a new user:

• General tab:
  • First name: hostname-SAS
  • Display name: hostname-SAS
• Account tab:
  • User login name: hostname-SAS
  • Use a long random password
  • Password never expires
  • User cannot change password
  • Do not require Kerberos preauthentication

Replacing hostname above and below with the host name of the machine.

Then use the following command to register SAS SPNs with that service account:

setspn -u -s SAS/hostname hostname-SAS
setspn -u -s SAS/hostname.example.com hostname-SAS

Replacing example.com with the appropriate domain name. If you use DNS aliases for the host then you will need to add those short and fully-qualified ones too.

The following command can be used to review SPNs with that service account:

setspn -l hostname-SAS

If necessary setspn -u -d spn user can be used to remove any added in error.

With SAS 9.4 you no longer need to add port numbers to the SPN which was only required for SAS 9.3 and earlier.

With the service account set up you can then extract a keytab for SAS to use.

[PaulHomes]

I forgot to add that I also mark the hostname computer and hostname-SAS service accounts in AD as Trusted for Delegation so you can use IWA for multiple hops for things like UNC file access, SQL Server database access etc. 

[shoin]

Dear Paul, much thanks.  Lots of information and I read through all the links you provided.  Again thank you very much.

I am configuring the environment w IWA on a Linux x64.  Currently only want desktop SAS clients SSO.

I have two questions that I could not find answers to:

1. Registering SPN, is it mandatory to do FQDN hostname + short-name?

2. Keytab file.  In my topology, 2 machines plus clients, do I need to have the generated keytab file one each per node?  Or just on metadata node? If one, should I combine all entries?  From my understanding, the keytab file ought to list all UPNs and SPNs, should be accessible only to the installer ID.  

These are the two last lingering item if you could shed some light on.

Thank you again for wonderful information and the help!

S

[PaulHomes · Accepted solution]

Thanks for the feedback. Glad the info's helpful.

1) When clients (such as SAS EG, SAS MC, web browser etc) want to work with a service using kerberos they construct an SPN using a host name. Some clients/users may use FQDN some may use short names. In some scenarios they may use host name aliases. Essentially all of the possible host names that could be used should be registered in SPNs for that service (account). If a client uses a host name to construct an SPN which is not found then the connection will fail. You add multiple SPNs to handle all the possibilities.  Perhaps if you can guarantee only one form will be used then you might get away with one SPN, but I have always used both FQDN and short name versions (plus any DNS aliases). I wouldn't skimp here ... it's very quick and easy to add them ... but it's tricky and time consuming to troubleshoot them 😉

2) I believe that recommended security practice (to limit the scope of access/changes when a keytab is lost/replaced) is to use a different account/keytab per service. You will see in Stuart's SASGF 2016 paper he says:

There is a choice as to either using one user account per service or link multiple services to one account. While having multiple services  linked to one account can simplify the management of the environment, it will mean that any security breach of this account impacts all the services. As such, many organizations will require a separate user account per service.

So in your split metadata/compute server environment, you may want to use separate service accounts/keytabs for the the metadata server machine and object spawner (compute) machine. This is just like the examples given Stuart's SASGF 2016 paper. In my blog posts you may only see one used for both because in my small lab environment I have all the server components on one host (and it's easier to write about one). If you end up configuring web for IWA then you will also want one for the mid-tier. You should also consult with your organization's security team on their policies in this regard (to save you time possibly having to make changes later).

... and yes the keytab file should only be accessible to the process owner of the SAS services (often called sas or sasinst). I chown sas:sas and chmod 400 mine.