Configuring and Securing Complex BI Applications in a SharePoint 2010 Environment with SQL Server 2012 Tom Wisnowski - Architect, Microsoft Consulting Service

Hello. Welcome to Configuring and Securing Complex BI Applications in a SharePoint 2010 Environment with SQL Server 2012. My name is Tom Wisnowski, and I'm an architect with Microsoft Consulting Service.

In today's lesson we're going to cover four modules. In module one we're going to look at the basic challenge we face as infrastructure architects when we're planning scale-out architectures that require pass-through authentication. From there we're going to take a foundational look at Kerberos to understand how that technology can help us overcome those challenges. Now, if you're familiar with Kerberos, I suggest you skip onto module two. In module two we start to look at some of the new features of SQL Server 2012, in particular the new Service Account Type support. We're going to take a look at how those new account types affect our

Kerberos planning, and then we're going to take a deep dive look at how we actually configure Kerberos for the relational database engine. In module three we move on to Reporting Services. Reporting Services in 2012 has significantly changed from the previous versions. We're going to take a look at the new architecture, we're also going to take a look at some of the new features of Reporting Services to see how we can leverage some of the advanced capabilities to get around some of our double-hop challenges beyond just using Kerberos. We'll then take a look at an example of how we configure pass-through authentication with SQL Server Reporting Services 2012. Finally, we'll wrap up with module four. In module four we're going to take a look at more complex scenarios. These might be scenarios that you're more familiar with in your own environments where maybe you have to deal with multiple domains or maybe multiple forests. Maybe you even have a cloud boundary you have to cross. We'll take a look at some of the challenges that we face in those scenarios, and how we can leverage some of the capabilities of SQL Server 2012 to overcome those issues.

Now, before we begin, everything you see here is going to be based on Windows Server 2008 R2 service pack 1, SharePoint Server 2010 service pack 1 plus the December 2012 CU, and SQL Server 2012 release candidate zero. What you will not see today are future versions of Windows Server or SharePoint Server. In addition, we are currently using the release candidate of SQL Server, so there is a possibility that once you see the final version of SQL some of the things you see in this video may have changed.

Module one.

In module one you'll walk away being able to describe how scale-out affects authentication in certain scenarios, and then you'll also gain a foundational understanding of Kerberos to help you configure and triage Kerberos in your own environments.

So, let's take a look at a scenario that's probably pretty familiar to everyone here. In this scenario you're getting ready to build a BI solution. So, you're standing up a development environment and you've installed the typical software you would expect. You have SQL Server 2012, you have SharePoint Server 2010, maybe it's Visual Studio, in addition Internet Explorer, and you've deployed all this to a development machine. This is a single server box, maybe a virtual machine, and you go and you build your first solution. Maybe that's the Excel Services dashboard you've always wanted to build. You build that out, you deploy it, you run it, and magically everything works.

So, now confident in what you've built, you decide it's time to deploy to maybe a preproduction environment or maybe production. Now, this environment looks slightly different. In this scenario you have multiple servers to deal with. You may have a SharePoint Server or servers that act as web front-ends, you may have multiple SharePoint Servers acting as application servers, and finally you may have one or more SQL Servers hosting that data that you need for your dashboard.

You take that solution that you just developed in your development environment, you deploy it, and everything seems to deploy correctly. You bring up the site, you bring up your dashboard; so far everything is looking good. But then you click that little data refresh button and all of a sudden bang, it doesn't work. You start digging around the logs a little bit, and you see this error, something about anonymous logon. And you wonder to yourself, why is it giving me an error about anonymous logon? I didn't configure my solution to use anonymous authentication.

So, what happened?

Well, what you most likely ran into is the double-hop issue. Let's take a look at this issue in a little bit more detail.

So, in this case we have the client, Bob. Bob is going to try to access some resource on SharePoint, say the Excel Services dashboard. That dashboard needs to authenticate as Bob to SQL Server to grab that data, render it, and return it back to Bob. So, the first thing Bob has to do is he has to authenticate to SharePoint. This is hop number one. Now, if we're using the default authentication mechanism in classic mode this is going to be NTLM authentication. What's going to happen is SharePoint is going to challenge Bob, Bob is then going to be able to respond to that challenge using NTLM and prove his identity. Now, Bob is going to bring up the dashboard, and he's going to click refresh. At that point, SharePoint is going to have to delegate Bob's identity back to SQL Server. Now, this delegation only occurs if Excel Services or the service in question has been configured to use pass-through authentication, but the challenge we have is if we're using NTLM authentication in our environment, NTLM cannot perform that second hop. When the SQL Server challenges SharePoint, SharePoint is not going to be able to respond to the challenge and it's not going to be able to use Bob's identity to authenticate.

So, Kerberos, what is it and how does it help us in this scenario? Well, it's an authentication protocol. It's Windows integrated so it's built into our Negotiate SSP. It's based on a ticket exchange architecture which leverages symmetric encryption to pass these tickets back and forth. But most importantly, the one thing it enables that we need that NTLM does not provide is it allows identity delegation.

So, when you're looking to learn about Kerberos, I suggest you look at the key concepts behind the technology. Part of that would be the components involved. Now, these are the components we just looked at on the previous slide. This includes the client. This is a person or a service that needs to consume another service and authenticate. You have the service itself, which needs to authenticate the caller, and potentially then delegate that caller's identity to another service down the road. And then finally, we have this trusted middleman called the Key Distribution Center. In a Windows realm this is going to be your Active Directory controller, and that Active Directory controller has two key services that are going to be giving us the tickets we need for this authentication scheme to work. The first is the Authentication Service, and the second is the Ticket Granting Service. We'll take a better look at both of those in a second. Now, the tickets that are going to be exchanged back and forth, there's two types of tickets you need to be aware of. First is the Ticket Granting Ticket. The Ticket Granting Ticket basically allows us to go back to the KDC at a later time to grab the second type of ticket, which is a Service Ticket. It's the Service Ticket which has the identity information that we need to be able to either authenticate and/or delegate to another service. Now, how does this all flow? Well, through a number of sub-protocols. The first protocol we'll look at would be the Authentication Service requests and replies. This is how we exchange Ticket Granting Tickets. Then we have the Ticket Granting Service request and reply. This is how we exchange Service Tickets back and forth. And then finally the application request and reply. This is how we actually pass a Service Ticket to the service in question.

So, let's take a look at that in a little greater detail. Now, in this scenario we have Bob the client. Bob is logging into his desktop. We have a server, and that server is running a particular service that Bob would like to authenticate to. In this case it's maybe the Internet portal and that portal is running with a particular identity, SVC Portal. Now, it's important to understand that key concept. Service Portal is an identity that the KDC understands, it's an account in Active Directory, and it has a secret key, something derived basically from the password we use for that account. Now, when we've configured that portal application we had to specify that secret information when we typed in the password for that service account, either through IIS or if this was SharePoint when you actually set up that managed account. Now, the KDC, it's aware of the account, it is the Active Directory, it is the directory that contains all the account information, but what it doesn't know by default are these services that that particular account is being used in. So, to actually associate the account to a service we use something special called a Service Principal Name or SPN or "spin" for short. The SPN, all that is is just a unique identifier that identifies a service that we then can use to associate a service to a particular account in a directory. So, let's see why that's important.

So, the first thing that happens when Bob logs in, in the morning, is his environment or his machine is going to send off an authentication service request, and if he logs in successfully he'll get a reply. And in that reply there's going to be a special type of ticket. This is the first ticket he receives. That ticket is the Ticket Granting Ticket. That is what Bob will use to go back to the KDC at a later point to get Service Tickets as needed when he tries to authenticate with various services.

So, now Bob is going to try to hit that dashboard. Well, Bob's machine, he's going to open up the browser and he's going to make his first request. That request will be denied by the server. But with that denial the server will also tell his browser what authentication schemes that that server supports or that application supports. Most likely that's going to be Negotiate. So his browser is going to look at that and realize, okay, the server will support Negotiate; I'm going to try to use Kerberos authentication.

At that point, the browser is going to go off and make a Ticket Granting Service request. He's going to pass the original Ticket Granting Ticket, and with that ticket the Service Principal Name for the service which the client wants to authenticate to. Now, if that Service Principal Name is registered and found in the KDC -- so that's a key point -- if it's found successfully, what Bob will get back is a second type of ticket, the Service Ticket. The Service Ticket contains Bob's identity, but note that Bob's identity is in that little envelope that's secured with a lock. What's going on there is the Service Ticket is actually encrypted with that secret that's derived from the password that only the directory and the server knows that's the password for SVC Portal. This is important. This is what ensures Bob cannot tamper with his identity, Bob cannot decrypt that so that he could potentially alter his ticket and maybe elevate his privileges.

So, now that we have the Service Ticket, Bob's machine will now go back again, making the same request, but this time passing the Service Ticket with a response if the Service Ticket is decrypted successfully, Bob will get back the dashboard he was looking for.

So, Service Principal Names. Service Principal Names are probably one of the most important components of a Kerberos architecture. If Service Principal Names are not configured correctly, Kerberos will not work. This is typically nine times out of 10 the issue I deal with when I'm looking at environments where Kerberos seems to be failing. Either the Service Principal Names are not registered, they're registered incorrectly, or we have multiple duplicate SPNs in the environment. So, again what is a Service Principal Name? It's a unique identifier for a service running on the server. We associate Service Principal Names to accounts, either users or computers, in the Active Directory, and you'll see that we store the values, these Service Principal Names, in an attribute called ServicePrincipalName in AD. We recommend that you configure your Service Principal Names using a command line tool called SETSPN. There are other mechanisms you can use to register Service Principal Names. You can use the user computer snap-in, you can even use PowerShell or script, but I recommend SETSPN because there are some special features of SETSPN that will do things like check for duplicates before it registers a SPN and allow you to query for SPN configuration in the environment, which is beneficial when you're looking to either configure your SPNs for the first time or you're triaging various Kerberos issues. So, these SPNs they're technically just a unique identifier, just a string, but they do follow a particular pattern or format, and you see that here. Now, depending on the service, the service class will be different. So, in the examples that we have below the first Service Principal Name you're looking at is for an HTTP service. Note that

the service class is HTTP. But now the second Service Principal Name is for SQL Server, specifically for the database engine or the relational database engine. Note that the SPN does look like a URL but it is not a URL, and this is a very common mistake. More often than not I always seem to find SPNs that have HTTP:// instead of HTTP/. So, for more information you can find plenty of information about how to register Service Principal Names on TechNet. In addition, there's a great whitepaper on configuring Kerberos for SharePoint that you could look at that goes into this in great detail.

So, now let's take a look at a quick demo. Let's take a look at configuring Kerberos in a typical SharePoint environment. We'll take a look at how those tickets are actually exchanged, and we'll look at how we use Netmon to diagnose and triage Kerberos issues in our environment. Okay, so in this demo what we're going to look at is how to an analyze Kerberos traffic using Network Monitor. Understanding the basics of how Kerberos works on the wire will help you triage Kerberos configurations in your own environment. So, if we take a look at my environment, you can see that I'm running a pretty basic scale-out architecture where I have an Active Directory controller, a Windows 7 client, a SQL Server, and then a couple of SharePoint Servers. So, right now we're taking a look at my client, and what we're going to do just for this demo is take a look at the traffic that's requested or the requests that are made across the wire when I pull up my SharePoint site. So, I've preconfigured this particular web application, MVA Demo, to use Kerberos authentication. So, we're going to take a look at what that looks like in Network Monitor. Now, before we begin, we're actually going to clear our ticket cache. So, Kerberos tickets are cached for every session, and if I use klist you can see that I have a number of tickets already cached.

Now, if the tickets are cached, we won't see them being requested on the wire, and so that's not going to be good for demo purposes. So, I'm going to go ahead and clear this out. We use the command "purge" to purge the cache. Okay, so now we have no tickets. Check that. Yep, no tickets. Now, I'm going to come over and I'm going to run Network Monitor. Now, note that I have a display filter applied: ProtocolName=KerberosV5. That's going to help us see just the Kerberos traffic we're interested in. So, I'm going to go ahead and start this. Okay. I'm going to come back here, and I'm just going to check to make sure we still don't have any tickets in our cache. Great. Now I'm going to come over to Internet Explorer and I'm going to do a refresh. Okay, we've refreshed, come back to Network Monitor and stop the capture. So, let's take a look at a few frames we've captured. So, I'm going to go ahead and zoom in here for a second, and you can see a number of requests and replies. I'm going to go ahead and scroll over so you can see that better. So, let's take a look at what's going on. So, the first thing we talked about was at the beginning of the process the client has to request a Ticket Granting Ticket. So, you can see here that's that first request. We're asking for a service, the Kerberos Ticket Granting Ticket service, for VMLAB.LOCAL domain. Now, we initially get back an error because in this particular Windows environment we're requiring pre-authentication for Ticket Granting Tickets. That's not always the case. So, then we go back and re-request the same ticket, but this time we pre-authenticate. We get back a response, and you can see the response is successful, because we got back a ticket. Now, take a look at the next request. What we're requesting this time is a service ticket for our web application. So, you can see again in the service name we're asking for a Kerberos ticket for HTTP/mvademo.vmlab.local. This is critically important to understand. When you are debugging your environments, nine times out of 10 it's because Service Principal Names are either missing or misconfigured. This tells you specifically what service name Kerberos is looking for. So, this is a specific Service Principal Name that has to be registered in the directory for Kerberos to work. And then on success we get back the response and the client is administrator, as we would expect. So, now if we go back and look at klist again, just to confirm, you can see I've got a couple tickets in my cache. I have that Ticket Granting Ticket for my domain, and then I have the HTTP ticket for my web application. Let's go ahead and take a look at what this looks like for SQL Server. So, I'm going to go ahead, go back, start my capture, and now I'm going to come over and instead of refreshing the browser I'm going to go ahead and open up a quick query.

We're going to connect to the database engine, and that connection should have forced the Kerberos tickets we're looking for. So, I'm going to go ahead and go back to Network Monitor, I'm going to hit Stop, and we'll take a look at what's going on here. So, again note the service name is being requested. Now, this time we don't see the original Ticket Granting Ticket from the last example, and that's because that's already been cached, so we don't need to go and request it again. But you can see that I'm connecting to the relational database engine and that service name is MSSQLSvc. We'll talk about Service Principal Names in the next demo, but just note that it's the same method to debug Kerberos regardless of the service you're talking about. You should always see a request for the service with a service name and the value that has to be registered in your directory. And with that, that concludes this demo.

Module two.

In module two we're going to take a look at the various Service Principal Names you need to register depending on the SQL services you run in your environment. In addition, we'll take a look at the new service account types supported by SQL Server 2012. And then finally, we're going to take a look at how we configure Kerberos for the relational database engine and how we can validate that configuration.

So, first, let's take a look at the common SQL Service Principal Names you'll be defining in your environment. First, let's take a look at the relational database engine. For the relational database engine you're going to configure multiple Service Principal Names. Note that the service class always starts with MSSqlSvc, and then you're going to configure both the host name and the fully qualified domain name. In addition, you also need to include port. So, if you're running on the

standard port, 1433, you would use 1433, and if you're using a non-default port, you would put that port number here. Finally, if you're using a named instance, you also need to include the instance name using the forward slash instance syntax. Now, with named instances, because they're leveraging dynamic ports, which leverages SQL browser, you need to also ensure that SQL browser is configured for Kerberos so that it returns the correct connection string to your client. You do this by registering a different service class, the MSOLAPDisco.3 service class, and then you register the server host name and the server host fully qualified domain name.

For Analysis Services it's very similar. You have a new service class, which is MSOLAPSvc.3, but then what's slightly different with Analysis Services is you have to take a look at how you register instance names. Note that unlike the relational database engine you don't use the forward slash instance name syntax, you actually include the instance name where you typically would put port. Note that with Analysis Services you do not use port number here. With the same thing as the relational database engine you have to register again the SQL browser service when you're using instance names or instances of Analysis Services, and you use the same syntax, MSOLAPDisco.3, the server host name and then the service host fully qualified name.

Also take note that there are some additional Service Principal Names supported. Typically, you're not going to run into these, but if you do want to specify your Service Principal Name in your connection string you can do that, and then here are some of the additional options you have available to you.

So, now let's take a look at account types. So, the first account type is your standard domain account. This is what you've been used to using throughout your career with managing SQL, pretty straightforward, nothing really new here. But now we also support Active Directory managed accounts. Now, we're not going to go into details around what a directory managed account is, but basically understand that a managed account is an account which the Active Directory manages the password and password policies and password reset. It's a special type of account that you have to register in a special way, and it requires Windows Server 2008 R2.

A full background on what Active Directory managed accounts are can be found in the link provided. Also note that if you're using Active Directory managed accounts you'll need to apply the hotfix noted here. Finally, we have virtual service accounts. Now, this is actually going to be the default service account type you're going to see when you go to install SQL Server 2012. These are local managed accounts, meaning that they really only exist within the context of the local machine, but that does not mean that you cannot connect to external services using these accounts. What will happen in that case is you're actually going to leverage the machine identity when that happens. And for more information you can follow the supplied link, and this too requires Windows Server 2008 R2.

So, standard service accounts. When we're using standard service accounts we use the Setspn tool. We prefer to use the -S option. The -S will actually check for duplicate SPNs for us, which is a pretty critical function. And then we supply the Service Principal Name -- these are the names we just covered -- and then finally the account that you're using for the SQL Server database engine.

Managed Service Accounts, again these are accounts that the Active Directory will manage for us, and they'll manage the passwords and the password reset and the password policies. This requires 2008 R2 schema. So, you have to have at least one 2008 R2 domain controller and you have to update the schema to 2008 R2. You have to create these accounts with PowerShell, and there's actually multiple steps when you do this. The first thing you do is you create the managed account. Then you have to associate a managed account with a computer and only one computer, and this is a key requirement here. The third point, you have to install that Managed Service Account on a computer which it was associated. And then finally you actually configure the service or services that need to use that managed account. Now, because the Managed Service Accounts are associated to a single computer, this means you cannot use them in clustering scenarios, nor can you use them as scenarios where you're using load balancing. Also note that you cannot use account names that are more than 15 characters in length, otherwise you will get an error when you try to run the commandlet to install the Managed Service Account. For more information you can follow the link supplied.

Virtual accounts, again these are the accounts that will appear by default. They always start with NT Service. So, that's the way you can quickly determine that you're using a virtual account. And you can see here from the screenshot we have an example of what the install experience looks like, and in this case we're going ahead and installing an instance of SQL Server using the new virtual account types. Note that the account format is NT Service, service, and then with an instance it's $<instanceid>. If we're going to register a Service Principal Name for a virtual account, you actually have to register it against the machine and not the account. This is because again the account is virtual. It doesn't actually exist in the directory; therefore there's no way to associate a SPN because it does not exist.

So, now let's take a look at the Service Principal Names we have to register in a SQL Server 2012 environment. We'll take a look at virtual service accounts and then the classic service account examples.

Okay, in this demo we're going to take a look at how we configure Kerberos for the relational database engine in SQL Server 2012. We're going to take a look at the Service Principal Names you'll typically have to register, and we'll take a look at how we confirm that configuration when we're done. So, if you skipped ahead from module one or the introduction, I'll just quickly introduce you to the environment. You can see here I've got a typical scale-out environment where I have an Active Directory controller, I've got a Windows 7 client, I've got a single server of SQL Server and multiple SharePoint Servers, and a web front-end and an application tier. So, let's go ahead and first take a look at our SQL Server. So, first, let's take a look at the particular services we're running on this server. So, you can see here I'm running a number of services. Let's zoom in. I'm running a named instance of Analysis Services. I've got a named instance of SQL Server. I've got a default instance of SQL Server and a default instance of Analysis Services. In addition, I'm running the agent and browser that you'd also expect. So, if we look at the accounts that I'm using to run these services, this might be new to you. So, let's go ahead and zoom in here and take a look. So, note that most of my services start with NT Service. This is the new virtual account type we just talked about. This is also going to be the default account type that's going to be selected when you install SQL Server. What's going on is this particular account only exists on this particular server, it does not exist in a directory. So, when we're registering Service Principal Names typically we register the Service Principal Name to the account that's running the service. In this case when you're running a virtual account you have to register the Service Principal Name to the machine running the service. So, let's go ahead and see what that looks like. So, I'm going to go ahead and open up a command prompt, and I'm going to go ahead and clear this real fast. I'm going to go ahead and show you Setspn. So, Setspn is a tool that we typically use to register Service Principal Names, but it also is a tool to query Service Principal Names and accounts. So, I'm going to list all the SPNs for a particular server, and I'm going to go ahead and show you my SQL Server, and we should see all the Service Principal Names that we need, because all of our services are running virtual accounts. Let that query for a second. Sometimes it takes a second or two to return. Okay, great. Let's go ahead and zoom in here.

So, I've got a number of Service Principal Names, all of which we've talked about. So, let's take a look at what we have. So, first the service class MSSQLSvc, this is for the database engine. You can see I've got my functionally qualified name, I've got name with port, I've got a named instance and another port. I also have Analysis Services. So, you can see here, here are my Analysis Services Service Principal Names, and this is for my named instance. And in addition for the browser I'm also running Kerberos, and you can see that I've registered my Disco SPNs. So, what does this look like? So, if I were to do this manually, I would run Setspn -S the SPN that I want to register -- so let's demonstrate what that would look like MSSQLSvc, for instance, forward slash the service, so the host that's running the service, in this case MVA SQL and let's fully qualify it, colon port, and then space and then the account that you want to associate the SPN to. Now, remember, if you're using typical domain service accounts or domain accounts, we're going to go ahead and register the SPN to that account, so something like this. But because we're using virtual accounts we register the Service Principal Name to the machine. In this case it's MVA SQL. Now, I'm going to run this, because that would create a duplicate SPN, and because we've actually used the -S parameter we'll actually get back an error saying there's a duplicate. But it takes a few seconds for that to check and for the result to come back, so we're going to go ahead and skip that. Now let's go over to the directory just to take a peek at what this actually looks like. So, I'm going to go over to my directory controller. Now, I have to actually look at computers because remember I'm using virtual service accounts. So, I'm going to go find my SQL Server. Here we go, MVA SQL. I'm going to go ahead and open up the properties here. Now in the attribute editor I look for Service Principal Name, open this up. You can see all the Service Principal Names listed here, and you could also create new ones from this dialogue as well. Now, I typically don't recommend you use this to register your Service Principal Names, and that's because this particular editor lacks the feature of checking for duplicates. That's a pretty key feature that Setspn provides. So, I'm going to go ahead and cancel out of this. So, now we've registered the Service Principal Names, so let's go check to see if SQL Server is actually using Kerberos. So, now I'm going to go back to my client, and we're going to go ahead and check the relational database engine. So, I'm going to go ahead and open up a query. So, what this query does is uses a couple system views to display the connections and sessions that are currently active, and what I'm showing you is the session IDs, the logon being used, the host where the connection is being made, and the authentication scheme that was used. Now, just for demo purposes I'm also going to go ahead and I'm going to clear out my ticket cache, so against Klist purge. So, now we should have no tickets. Great.

I'm going to go back here and I'm going to reconnect. Okay. Now I'm going to go ahead and run the query, and if you look at the result you can see I have a number of sessions, various logons coming from different machines, all using Kerberos. This is how I know Kerberos is working correctly. Now, if you run this query from the SQL Server itself, you may notice that there are a few NTLM connections. You shouldn't be alarmed by that, because if you're running the Management Studio from the SQL Server locally, it's actually going to default and leverage NTML versus Kerberos. But the other remote services you should see they all connect with Kerberos. Let's also go and take a look at our ticket cache. This time we're just going to do a Klist. And we should see our SQL SPNs, and we do. So, again here's the SQL Server class, this was the instance I was connecting to on a default port, and at the domain we're at. So, that concludes our demo. So, we took a look at the Service Principal Names that we would have to register, we took a look at how you would use Setspn to register Service Principal Names, how you can list Service Principal Names, and then we took a look at Klist to see how we could actually see those in the cache, and then we also showed you a handy script that you can use to check to see how you're connecting to the relational database engine.

Module three.

In this module we're going to take a look at SQL Server Reporting Services 2012. We're going to look at it in SharePoint integration mode, and we're going to look at the architectural components that are new to SQL Server 2012 and contrast that to what we had in 2008 and 2008 R2. We're then going to describe how SharePoint 2010 identity delegation works, and how that affects SQL Server Reporting Services in this new configuration. And then finally, we'll have an example of how we configure pass-through authentication in SQL Reporting Services 2012 in SharePoint integration mode. Note that up to this point we've been heavily focused on Kerberos for identity delegation. We're also going to talk about some other options we have available to us in Reporting Services when we're connecting to Analysis Services, whether it be in the multidimensional mode or in the new tabular mode.

So, first let's take a look at the Reporting Services architecture. This is Reporting Services 2012, and the first thing to note is SQL Server Reporting Services is now a SharePoint service application. This is a pretty big change from what we had in 2008 and 2008 R2. We now pick up the common architecture because we implement the service application framework. We now have the common components that make up service applications, which include the proxy components, the instance components, and we pick up all the benefits from that framework. We also pick up a dependency on the Claims to Windows Token Service. Now, the Claims to Windows Token Service basically is responsible for converting a claims identity into a Windows identity. We're going to learn a little bit more about when we leverage this and what does it mean in our environment. Note that for each instance of Reporting Services you have to run the Claims to Windows Token Service on each server. Also take note that because we now leverage the service application framework, when we have multiple instances of SQL Server Reporting Services we no longer have to worry about load balancing. This is because when we're in SharePoint integration mode it's that service application framework that's doing the load balancing for us.

So, now let's take a look at authentication in SharePoint 2010. So, we have clients. Clients are trying to authenticate with SharePoint, and they have a couple options. You can either leverage classic mode, which is either NTLM or Kerberos or you have some new claims options available to you. These may include federation with SAML claims or Windows claims or even FBA claims. Now, once you've authenticated, your identity will be normalized into a claim. Now, this is a very important concept to understand. Regardless of the incoming authentication provider, once you've authenticated with a farm, any inter-farm communications that require authentication are going to leverage claims authentication. So, in essence you lose your

Windows identity once you moved off of the web front-end and you're executing code on the application servers. And this is important when we start to look at the SQL Server Reporting Services architecture, because it now follows that same service application framework architecture, and now also picks up the same claims authentication architecture. Once we've authenticated within the farm, there are scenarios where we may have to go outbound. In BI scenarios this is very common, you're going to go query external systems to pull in data to report on. So, outbound we can either go outbound with classic mode and we'll look at how the Claims to Windows Token Service is used to do that. Or in some scenarios, depending on the service application in question, you can also use those claims that we're using inter-farm and we can pass those outbound.

So, again let's just talk about identity normalization. The key point to take away here is regardless of the incoming authentication mode, SharePoint is going to normalize you down into an SPUser and into a claim set. This means that once you've moved off the web front-end you lose your Windows identity. You're now just a set of claims being passed around.

So, this architecture introduced a lot of improvements from previous versions of SharePoint. We won't go into the details, but it does introduce a challenge. So, let's take a look at the following scenario. So, if we have Bob and Bob is going to authenticate with let's say NTLM to web front-end, and then Bob is going to pull up a SQL Server Reporting Services 2012 report on the application server, the application server is going to authenticate Bob using the claim that the web front-end provides. But what happens when that Reporting Services server needs to authenticate to a back-end SQL Server using Bob's credentials? In SQL Server 2012 we still do not support claims authentication for the relational database engine or Reporting Services outside of SharePoint integration mode. So, how do we convert the claim back into a Windows identity that could be used to authenticate with SQL?

This is where the Claims to Windows Token Service comes into play. Just like the name sounds, it's responsible for turning a claim into a Windows token. What it basically does is it looks at the incoming claim. In particular it actually looks at just a claim and a claim value, which is your UPN. It then takes that UPN and does a special type of logon. So, we get an S4U logon. This basically means it's able to log on that particular user and get their Windows identity without knowing the password. Now, you can imagine the service that's running the Claims to Windows Token Service, it requires special permissions to do this, and we'll talk about that in a minute. But once it has that Windows identity, it could then pass that Kerberos ticket to any service, which then can pass that back to a service that needs to authenticate the caller. Now, to actually do that we have to configure a special type of Kerberos delegation. This is Kerberos constrained delegation. It's very important to note this. When you're using the Claims to Windows Token Service, and this means all the service applications that leverage the service application framework, in other words Reporting Services, Excel Service, PerformancePoint, all these services require Kerberos constrained delegation when you're configuring delegation out of the farm. And we'll talk about what that means in a minute.

So, let's take a look at how this actually works. So, first we have Bob coming into the web front-end using NTLM. The web front-end authenticates Bob, and now the web front-end goes back to the application server, in this case Reporting Services, using Bob's claim set. SSRS takes a look at that claim and says, oh, okay, I know who Bob is, but I need to go off and I need to grab data from SQL Server, so I'm going to use the local Claims to Windows Token Service to translate that claim into Bob's Windows identity. The Claims to Windows Token Service does the S4U logon, and it gets a Kerberos ticket. It then passes that Kerberos ticket back to the service application, in this case Reporting Services, and then Reporting Services is able to delegate that ticket all the way back to SQL Server. Remember the delegation here is Kerberos constrained delegation.

So, what does this mean? Well, since we're using the Claims to Windows Token Service we have to think about a couple things. First, we have to think about the security of the environment. The Claims to Windows Token Service to do the S4U logon requires Act as Operating System privileges. Now, this is the very highest, most privileged right you can give to a service on a box. By default, the Claims to Windows Token Service runs as local system, but we recommend typically that you run this as a service account. When you run this as a service account, you're going to have to remember to give that service account Act as Operating System and in addition some other privileges. One is impersonate a client, and then the other is run as service. Also note that because the operation that the Claims to Windows Token Service performs, which is this logon without password, because it's so highly privileged, the Claims to Windows Token Service uses local procedure calls, or LPC, to communicate with its clients to perform this operation. What this means is it's not actually listening on any network port, you can't connect to a remote instance of the Claims to Windows Token Service. This is why you must run this service on every machine that's running the service application that requires it. Now, because this privilege operation could potentially be used maliciously we also enforce other restrictions. The type of ticket that it gets back has to be a constrained ticket. This means we have to define the specific services that this ticket can be delegated to. When we do this, however, we pick up a constraint. The constraint is we can no longer delegate that identity across a domain boundary. So, this means if I have SharePoint running in one domain and I have my data source running in another, I can not ask the Reporting Services instance to go and grab a Kerberos ticket for a user and delegate it over that domain boundary. I have to go and use one of the other authentication options available to me. Also note that in the current version of SharePoint this requires the web front-ends to either be using windows-claims or Windows classic mode. Some of the services that you're probably familiar with that leverage this architecture, in particular the Claims to Windows Token Service, include Excel Services, PerformancePoint, and now SQL Reporting Services 2012.

We also require the Claims to Windows Token Service for PowerPivot, but we don't actually need it to delegation. We actually use it internally. So, I don't list it here, but just be aware that it is leveraged with PowerPivot as well.

So, now how do we configure Kerberos delegation for Reporting Services? So, we have to use constrained delegation with protocol transition. So, this means with Reporting Services service account we're going to go ahead and specifically set up constrained delegation to every SQL Server service that we need to connect to or every Analysis Services instance that we connect to. We'll do the same thing for Excel services and for PerformancePoint. In addition, we also have to set up delegation from the Claims to Windows Token Service to those very same services. The reason why we also need it on the Claims to Windows Token Service is because it is the service that actually does the work to request the logon. So, it actually has to also have the delegation setting setup correctly. We'll take a look at this in greater detail in a second.

So, let's take a look at what this looks like at a high level. So, in our example here we have the user coming in with either classic authentication or windows-claims. They authenticate with the web front-end, and then the web front-end has service application components and a service application proxy running on it. The web front-end will use claims to pass the identity back to the application server. In our example it's Reporting Services. And then Reporting Services, if it's configured to use pass-through authentication, will then go to the Claims to Windows Token Service, grab the identity that's needed, and as long as the delegation has been set up correctly in Active Directory -- and again the delegation has to be set up between the service itself and the data source, in addition the Claims to Windows Token Service and the data source -- if both those are configured correctly, we get back the token that's needed and then we're able to pass back that ticket all the way back to the data source and authenticate.

So, now let's take a look at what this looks like in SQL Server Reporting Services 2012.

Okay, in this demonstration we're going to take a deep dive look at SQL Server Reporting Services in SQL Server 2012. Now, in SQL Server 2012 we made some fundamental changes to the architecture Reporting Services when you run in SharePoint integration mode. What we've done is we've adopted the service application framework, meaning that Reporting Services, when running in integration mode, is now a full-fledged service application within SharePoint. So, let's take a look at what that means. So, the first thing we'll do is we'll take a look at application management. So, I'm in central administration, and I've gone over to application management, and I'm going to scroll down and I'm going to manage my service applications. So, the first thing you'll notice when I click new is we've got a new type of service application. This is something you haven't seen before if you have not tried this with SQL Server 2012. You have the SQL Server Reporting Services service application. So, let's take a look at what we would do to install and configure the service application. So, after you've installed the actual service application from the SQL media -- so you first have to deploy the Reporting Services bits from the SQL Server install -- you then have to go into central administration and you have to configure a running instance of that service on one or more of your application servers, and then you have to create that service application here in service application management. So, first let's go back and let's take a look at running the instance. So, we're going to go to managed services on a server, and we're going to select one or more application servers. In this case I already have mine selected, but you may have to change the server selected here in your particular example. And I'm going to come down and I'm going to look for the SQL Server Reporting Services service. Now, if you do not see this service, then you have not installed this particular feature from SQL Server's install media. Once you install it, you'll see this service available and you will have to manually start it on every server that you want to run this particular service. In this case I'm running it just on one application server, my MVA app server. And then you're going to go ahead and go into application management, and you're going to go Manage Service Applications, and you're going to create a new instance of the service application. So, this is basically telling SharePoint I want to run this particular service application, I'm going to tell you the configuration of that application, I'm going to add this proxy to either the default proxy group or a new group so that web front-ends can access and talk to this particular service application. So, I'm going to go ahead and hit new. You would typically provide a name, typically create a new application pool. You would select the managed service account you want to use. I've already pre-created one. Provide some basic information about the database server you want

to use, the name of the database that you want to have, and then the web applications you want to associate the service to. Now, I'm not going to do this because I've already done this, and you can see here here's my configuration, here's my service application. And if I bring up properties, this is the particular configuration, and I've already associated it to my demo web application. So, now in addition to having to have to have the service or the Reporting Services service instance running and the service application instantiated, you also have to run the Claims to Windows Token Service on that server. So, again if we go back and take a look at central administration, and services on server, there's a service called the Claims to Windows Token Service. This has to be started on the application server and every application server that runs Reporting Services. It actually has to run on every application server running any service application that requires the Claims to Windows Token Service, because it only accepts local calls. You cannot configure one instance of this and have all your service applications talking over the network to consume its services. So, we've already started this service. So, let's go ahead and take a look at the service accounts that I'm using for these services. This is going to be important to note because we're going to have to use these services to configure delegation to delegate authentication from Reporting Services to our data source, in this case SQL Server. So, let's go ahead and go back to central administration, and I'm going to quickly note down the accounts that we're using. So, if I look again at security, and configure service accounts, I can go ahead and select my service application for Reporting Services. You can see here I'm running this service using MVA SSRS, so we'll make a note of that, and then also if we look at the Claims to Windows Token Service you'll see here that I'm actually using a domain account, and the domain account is MVA Claims to Windows Token Service. The default is going to be local system, but I've elected to use a domain account for demonstrations purposes. So, now I'm going to go over and I'm going to go over to the application server, and I'm going to show you how you would actually configure the Claims to Windows Token Service if you elected to use a domain account. So, if I come over here and I go over to services, the first thing we'll see is the Claims to Windows Token Service. If I zoom in, I've actually got a Windows service called the Claims to Windows Token Service. It's started and it's using my service account. Now, you will not see this listed if you have not actually started the service on the server from central administration. When you install SharePoint, it is not going to run this service or deploy this service by default. You have to go through central administration and go to services on server and start it on every server where you need it. So, now because we're running again as a domain account there are additional privileges that this domain account needs on every server where it's running.

So, I'm going to go ahead and take a look at administration tools, we're going to go look at the local security policy, and we're going to go into local policies, user rights assignment, and let's take a look at the rights that I've granted this particular account. The first one you'll note, and probably the most important, is Act as Part of Operating System. This is the uber permission. This is what allows the Claims to Windows Token Service to perform that special S4U logon that allows it to get a Kerberos ticket for a particular account without knowing its password. You can imagine that is a very privileged permission that you're giving this service account, so you do not want to give this out to too many different services. In addition, we need a few others. We do need the impersonate client. So, if we come down here you can see Impersonate client after Authentication. I have my service account listed here. And then also logon as service, because it is a Windows Server running on this box. And you can see my service account listed here. Now, if you had started the service before you came through and configured these permissions, you're actually going to have to restart the Claims to Windows Token Service, restart it here, to force this account to log on again. That's so that it refreshes its permission set and it picks up those special privileges it needs. So, now that we have SQL Server Reporting Services running and we've got the Claims to Windows Token Service running on the application server, the next thing we need to do is configure delegation. So, for that I'm going to go over to my Active Directory controller and I'll look at my service accounts that I need to configure delegation for. So, the first one we'll do is the Reporting Services service account. So, I'm going to go ahead open it up, and you're going to note that I have a tab called Delegation. What you need to know is this tab will not appear unless the account in question has a Service Principal Name associated to it. So, the question is, what Service Principal Name would we register for the SQL Server Reporting Services account? Remember that we don't actually ever connect to this service using Kerberos. So, technically there isn't a Service Principal Name or at least a well-known name we should be registering. So, if I look at Service Principal Name, you can see here I have registered SP/SSRS. This is a completely arbitrary dummy Service Principal Name that I only use to show the delegation tab that I previously showed you. This could actually be anything you want. This could be FOO, this could be WHAT/EVER; it does not matter. Remember we are not connecting to Reporting Services using Kerberos when it's in SharePoint integration mode, so it does not matter what SPN I'm using here. Now, I do like to use a well-known format that at least is well-known to me, so that when I'm querying all the Service Principal Names in my directory I know when I see things like SP/ that these are for SharePoint services and they're dummy SPNs. So, I'm going to go ahead and just cancel out this.

So, I've got a Service Principal Name, I've saved and closed the dialogue, and then when I come back in I get a delegation tab. So, now within delegation we've got a few options. Let's take a look at each one. So, the first one is "Do not trust this user for delegation." Obviously not what we want, we want delegation, so we can't use this. The next one says, "Trust this user for delegation to any service (Kerberos only)." So, what this is is unconstrained delegation. So, this is typically what you configure in most of your environments where you want a particular service to be able to delegate to any service that accepts Kerberos authentication. One of the nice features of this option is that this allows you to cross some domain boundaries. However, because we're using the Claims to Windows Token Service, we cannot use this option, this is not available to us. Because the Claims to Windows Token Service does the S4U logon, we have to configure constrained delegation, our third option, and that is "Trust this user for delegation to specified services only." So, now with this we have two sub-options. One is Kerberos only, and the second one is any authentication protocol. Use Kerberos only means I only want to delegate in the situation where the service that's doing the delegation actually has a Kerberos ticket to start with. So, it's going to take the ticket it has and it's going to delegate it back to that service downstream. In our case that is not what we have. We actually have to use the second option, use any authentication protocol. If you remember back to the slide that talked to the delegation and identity architecture of SharePoint, no matter what authentication method we're using when we come into the farm, we get normalized into a claim. So, this means the SQL Server Reporting Services service only has my claim when it's trying to do the S4U logon. So, I have to transition from claims to a Windows identity, and that's what this option is. This means use protocol transition. Once we've selected this, you actually have to select the particular services that you want to allow this service account to delegate to. So, let's take a look at what that looks like. I'm going to click Add. Now you have to select the user computer that has the SPNs registered to it, and then it will allow you to select all the services that have been registered. So, I'm going to select this. Now because I'm using virtual accounts with SQL Server, if you remember from the previous demo, I actually have to query for my SQL Server and not an account that would be running SQL Server services. So, I'm going to go ahead and just check the name here, resolves, and click okay. So, note that I have all these services registered on this box. So, what you have to do is you actually have to go through this list and find the particular service that you want to delegate to. Now, it's very easy just see all these services and click okay. I've done that many times. If you do that, you will not see any services listed here. If that's the case, you are not actually doing

delegation, you did not configure delegation correctly. I actually have to select the services that I want to delegate to. In our example we're going to delegate to the default instance of SQL Server running on another box. So, we're going to go ahead and select our services here. You click okay, and the services should appear in this box. Again, if you do not see the services listed here, the delegation settings are not configured correctly. All right, once you have this, you should have delegation configured correctly for this particular service account. Now, remember when configuring delegation you always configure delegation for the service and for Claims to Windows Token Service. So, we're not going to go through all those instructions, but I'll quickly show you again the highlights of what we talked about. We look for the Service Principal Name. You can see I've registered my dummy Service Principal Name. That gives me access to this tab, delegation. I've configured "Trust this user for delegation to specified services." I'm using protocol transition. And again I've selected the services I need to delegate to. All right, so in the previous demo we already configured SQL Server to accept Kerberos authentication, so we know that works. We've now instantiated the Reporting Services Service Application within the farm, we created that service app, we've configured delegation for the accounts that we're using. So, let's go ahead and test this to see if it works. I'm going to come back to my client and now I'm going to go to my particular site. Now I’m going to go ahead and we'll go ahead and use Joe the user, that's fine. I'm going to come over to data connections. Now, in data connections I have a Reporting Services data source already preconfigured. I went ahead and created a report, and I published the report's data source before the demo. I'm going to go ahead and look at the properties, pretty basic stuff that you would expect, the data source type, this is SQL Server, our connection string, this is going to my SQL Server, and let's take a look at the credential options. So, I want to do pass-through authentication. In other words, I want to delegate the client's identity all the way back to SQL Server. That is this first option, use Windows Authentication. There are some additional options we have available to us that we'll talk about in a later demo. So, now I can go ahead and test the connection, and what you should see is this green "connection created successfully." If you get back any errors, especially if you get back a logon failed for anonymous logon, that typically means you have not configured delegation correctly, and you should look at the configuration of the Claims to Windows Token Service and your delegation settings in Active Directory to make sure they are correct. Okay, so now that we have tested the connection, we should be able to use it in a report.

So, now I'm going to go back and I'm going to look at my report and I've configured a very simple report that the only thing it does is shows me the active user and returns that through a system user query. And you can see that it has returned back the active user, in this case Joe. So, let me go back just to prove that that's working, I'm going to switch out and change the user to some other account, in this case administrator. I'm going to go back, I'm going to run that same report, and note that now it tells me that I have logged in with the administrator account on the SQL Server. So, what happened? Okay, so let's walk through this again. I'm coming in as administrator, I've authenticated to web front-end. In this case my application is configured for Kerberos. It doesn't have to be, but I'm using that anyway. At that point, SharePoint authenticates me, normalizes my identity down to an SPUser, and then when it makes the call to Reporting Services running on the application server it's going to authenticate to that service using claims authentication. So, I've basically lost my Windows token at that point, I'm not just a claim that's being passed over to the application server. The application server or Reporting Services will extract out the UPN claim out of my claim set -- all it is is basically my account name -- it's going to pass that to the local instance of the Claims to Windows Token Service running on the application server, Claims to Windows Token Service takes my account name, does an S4U logon, gets back a service ticket, passes that service ticket back to Reporting Services, and then Reporting Services forwards that on to SQL Server. And that is how you configure end-to-end delegation using Kerberos in SQL Server Reporting Services 2012.

Module four.

In this final module we're going to take a look at some of the more complex scenarios you may be facing in your environment. This is where typically you'll have multiple domains you'll have to deal with or maybe multiple forests, things that you have to consider when you're planning your BI architecture.

So, let's take a second and go back to the very first scenario we looked at. This is typically your developer scenario. This is where you have a single server hosting all the application services you need and the data you report against. In this scenario everything just works, configuration is simple, development is easy, and you typically are able to run your solutions without any issue.

But then we move into a more scaled out architecture. This is where you'll have multiple servers in your SharePoint far, you typically have multiple servers running different types of BI service applications, maybe PerformancePoint, Reporting Services or PowerPivot, and then your data typically exists on other servers, whether it be the SQL Server Analysis Services instances that you run or SQL Server relational databases. In this scenario things are a little bit more complex, but we still have lots of options available to us, because we're running within a single domain. In this case Kerberos is always an option for us. As long as we're running the Claims to Windows Token Service and we followed all the configuration guidelines, we'll be able to delegate identity from machine to machine without issue. If we choose not to use Kerberos for delegation, we can also leverage other methods that Analysis Services supports such as the EffectiveUserName through an RSDS file or a BISM file.

Then we move out to the most complex scenario. This is where you're dealing with one or more domains where you might have user domains or multiple user domains where users are coming in and authenticating to your SharePoint farm, your SharePoint farm may be running in its own

resource domain, and the solutions that are running within that farm may have to delegate identity and access resources in other resource domains, outside of the domain that SharePoint lives in. In this case Kerberos is really not an option for us, and the reason for that is moving to SQL Server 2012 Reporting Services is going to leverage the Claims to Windows Token Service, which, if we remember from previous modules, cannot delegate identity across a domain boundary. So, what do we do in this case? Well, note that in my additional resource domains I have SQL Server Analysis Services listed there, but mysteriously I don't have the relational database engine, and this is actually by design. So, with Analysis Services we actually have a technique called the EffectiveUserName, which allows us to pass a user context as part of the connection string, which Analysis Services is going to use to then execute the query and return back the result set you need, given that particular user context. That does not require Kerberos delegation. So, for scenarios where we're directly accessing Analysis Services data, whether it be through the multidimensional mode or even tabular mode, we can use the EffectiveUserName connection to cross a domain boundary. Now, to do that inside of your BI solution you're going to leverage one of two techniques. You're either going to configure Set Execution Context or User Execution Context inside of your Reporting Services data source file, your RSDS file, or you're going to leverage a BISM file, and we'll look at both of those in detail just in a second. Now, if you are trying to connect to a relational database engine, you really don't have very many options at this point, so you might want to explore other types of authentication other than passing back the user identity all the way back to your data source.

So, the RSDS file. So, how do we configure EffectiveUserName when we're using RSDS files?

Again, the EffectiveUserName is just a feature of Analysis Services. It's actually been there. It's supported even in the previous version before 2012. How we leverage this is we actually specify the EffectiveUserName in the connection string, and this requires that the caller have admin rights on the Analysis Services server. To use this when we're using an RSDS file we actually use the little option that's circled below, "set execution context to this account." What this means is Reporting Services is going to connect to the Analysis Services server using the username and password you specified, it's going to use that to execute the connection. So, we need to make sure that that account has the ability to authenticate with Analysis Services so there's some sort of trust, and that that account is an administrator on that particular Analysis Services server. But then what happens is the current user's username will be appended to the connection string using the EffectiveUserName parameter. So, then Analysis Services, as long as its account is an administrator on the box, it's going to go ahead and take a look at the EffectiveUserName, and execute the query given that particular user's security context.

So, how does work with a BI semantic file or BISM file for short?

So, in our example we have Bob. Bob is pulling up a report in a SharePoint environment. We have a web front-end, and on the web front-end we have a BISM file in a document library. If you're familiar with ODC files, this is very similar in concept, we just have the connection information stored in a separate file outside of our report. We have a separate application server running Reporting Services, and note that Reporting Services is running with a particular Service Account identity. We have a domain boundary between the farm and our data source, and our data source is Analysis Services either running in the multidimensional mode or in the tabular mode. So, first Bob is going to make a request for his particular report. Reporting Services, if the report's been configured to use a BISM file, will go out and open up that BISM file and get the connection information. In this case it's going to be the Analysis Services server you're trying to connect to and the database that you need to connect to. The first thing it's going to attempt is it's going to try a Kerberos logon. Now, if the Kerberos logon fails, which it should, because we cannot delegate Bob's identity across the domain boundary, what's going to happen is Reporting Services is going to make a second attempt. This time the application pool or Reporting Services is going to do a RevertToSelf, which means it's going to make an outbound call using the identity of the application pool, in this case our Service Account, it's going to do so to authenticate with Analysis Services using NTLM -- so this is a single hop, which is no issue -- and then if the connection is successful and the Service Account for the application pool, as long as it is an administrator on Analysis Services, it will connect using the EffectiveUserName in the connection string, and then that request or that query will be executed using Bob's security context. So, this is brand new to 2012. This is a way that we can actually use the Reporting Services application pool identity to connect to our Analysis Services instances and do pass-through authentication of the caller's identity, in this case Bob, all the way back to our Analysis Services instances even across domain boundaries.

Now, for this to work you, of course, have to have one way or two way trust set up so that the initial connection between the Reporting Services service app and Analysis Services can occur.

So, let's go over the options we have available to us in complex scenarios one more time. So, if we're in a single domain, Kerberos is one of the options we have available. We can use Kerberos, along with the Claims to Windows Token Service, and connect to our Analysis Services instances and our relational databases. We can also even in a single domain also use the techniques we just looked at. So, if we're connecting to Analysis Services we can also use the EffectiveUserName through a BISM or RSDS file. Now if we have multiple domains and we have to delegate identity across that boundary, then our only option available to us at this point is if we're connecting to SQL Server Analysis Services is to use again the BISM and RSDS file so that we can pass EffectiveUserName.

So, now let's take a look at a demo of how we can overcome some of the multi-domain issues using either a BISM file or RSDS file. Okay, so in our final demo we're going to take a look at a more advanced scenario. In this environment I have the previous domain that we've been looking at, but now I've added a new forest. I have the Contoso forest, and what I've done is I've installed SQL Server 2012 and I'm running a named instance of Analysis Services. So, we learned previously in our other presentations that we can no longer user Kerberos constrained delegation if I want to delegate the client identity across this domain boundary. So, this means we're going to have to leverage the EffectiveUserName feature of Analysis Services to be able to pass the client's identity over that boundary so that Analysis Services can authenticate and authorize the request. So, let's go ahead and take a look at how we do that. So, I'm going to go over first to my SQL Server in my Contoso domain, and I'm going to go ahead and I'm going to run a trace just so we can see what's going on. So, we're looking at logon events, and we're going to come back over to my Windows 7 client, and we're going to go ahead and open up the site, and in my data connections folder I have an RSDS file. So, first we'll take a look at how we configure RSDS to use EffectiveUserName. So, if we look at the credentials, so note I have my Data Source Type as Analysis Services. Remember this is only supported in Analysis Services, we can't do this with the relational database engine. My connection string, I'm connecting to my server that's in the remote forest and the catalog or the database that I'm interested in. Now let's take a look at credentials. So, if we zoom in here, we can see that instead of selecting Windows authentication, which would try to do Kerberos delegation, which, of course, wouldn't work because of the domain boundary or forest boundary, what I've selected here is used stored credentials. Now, stored credentials has a couple sub-options. So, when I select use as Windows credentials, the first thing that's going to happen here is when we make the connection it's going to attempt to connect using the credentials I specified here, and it's going to execute whatever query I'm executing using these credentials. So, that means regardless of the client coming in, whether it be the actual administrator or another user, it's always going to use these credentials to execute the query. That's called a trust subsystem model, and that may not be what we want. So, what we're trying to accomplish is actually having the active user's credentials or context be used when we execute the query on Analysis Services. So, what we have to do is we have to actually enable this second option down here, set execution context to this account.

When we do this -- let's go ahead and do that now -- when we do this what's going to happen is the connection is still going to be made initially with this credential, so Contoso\administrator and the password. So, we have to have some sort of trust that allows us to authenticate to Analysis Services using this credential. But instead of trying to use Kerberos to delegate the identity of the current user, in this case I'm the VMLab administrator, instead of using Kerberos we're actually going to pass that credential on the wire using the EffectiveUserName, and we'll see that in the profile trace in a second. So, now note that once I've selected set execution context I've made a change here, we have to go back and refresh the password. That's what this little warning is. So, I'm going to go ahead and do that. So, I'm going to go ahead and I'm going to test the connection. Okay, it was successful. So, let's go over to the SQL box. Let's take a look at the logins. So, the latest login we can see here is the Contoso administrator account, but now notice when we go into the Discover details, we have EffectiveUserName. Let's go ahead and zoom in on that. So, what Analysis Services is going to do is although we've connected with the Contoso administrator account, all of our queries will be executed with the VMLab administrator context. So, what we've done is basically been able to delegate the VMLab administrator client credential, if you will, across the wire, across the domain or forest boundary, but we did that without leveraging Kerberos. We're actually leveraging a specific feature of Analysis Services called the EffectiveUserName. Okay, so now that we've done this, let's go back and take a look at how we do this with a BISM file. Well, before we move on there's one thing I should mention. So, the reason why this works, and this is actually a requirement, if we go back to our Analysis Services, let's go ahead and open up Management Studio. I'm going to show you the security settings. So, one of the requirements is the account that you're connecting with has to be a server administrator. So, I'm going to go ahead and connect, and we'll show you security, and you can see here that the Contoso administrator account is, in fact, a server administrator, and that's what allows us to use the effective logon name. This does not mean the EffectiveUserName that we're passing has to be an administrator, it's only the credentials we're using to make the initial connection. You can see here I actually have added some other accounts as well, and the reason why I've done this is because when we're using a BISM file you're going to see that we actually connect with a couple different credentials. If we're testing the connection, so in other words we've created a new BISM file and we're selecting the test connection button, what's going to happen is we're going to try to connect with the farm accounts credentials and then pass EffectiveUserName. So, you can see here that's what I've done, I've added my farm credentials and I've made the farm and administrator on my instance.

Now, once you actually run the BISM file and you open up PowerView, what's going to happen is Reporting Services is going to make the connection. So, we need to make sure that the application pool identity we're using for Reporting Services is also a server administrator, and you can see that's what I've done here. So, let's go ahead and cancel out. So, let's go take a look at the BISM file. I'm going to go back to my client, and we'll go back to our connections. So, I've got an existing BISM file, but I'm going to go ahead and create a new one. Now, if you go into documents in your document library, and you select new document, if you do not see the BI Semantic Model connection, that's because you haven't added the content type to this particular library. I'll show you how to do that real fast just to help you out. So, if we go to library and we go to settings, and we scroll down, and you see content types, we want to add from existing content type, and then you'll select the BI Semantic Model connection. Once this is listed here and it's visible on the new button, we'll be able to create new connections. So, let's go back now to our library, and I'll quickly create a new one. So, when you create a new BI Semantic Model connection, go ahead and create a test one real fast, and actually what we'll do is we'll copy the settings from the other one. I don't remember the connection information, so let me go back. I'm going to go into my data connections and let's look at the BISM file I already have and edit that connection. I'm going to go ahead and copy out this database name; it's a pretty lengthy name, so kind of hard to type. So, let's go back and let's create a new connection. So, this is our demo connection, and the server name, and our named instance, and the database we want to connect to. Let's click okay, and that worked. All right, so now let's go ahead and open this up. Let's click on the connection file and Silverlight should load here in a second, and you can see we've made the connection. So, when we go in and we take a look again at Profiler, we should see Reporting Services has attempted to log in, there's our Reporting Services account, and then if we look at discovery information you can see that again EffectiveUserName has the administrator account that we were logged in as. Now, one thing also to note is you might notice the anonymous logons. So, if you remember back to the presentation, what we're doing under the covers is we're first trying to make an attempt using Kerberos. Because we can't delegate identity across the boundary, it's making an anonymous logon and failing. So, then we retry the connection using the application pool account that's running Reporting Services, passing EffectiveUserName for whatever the current user is. So, this is why you'll always see two connection attempts. You'll first see the first connection attempt which fails, which is Kerberos, and then we follow up with the EffectiveUserName attempt.

With that, that wraps up this demo.

Okay, let's go ahead and wrap up with a little recap of what we learned today. So, we started off looking at NTLM and the double hop issue. We learned how delegation and a scale-out architecture can be challenging, and how NTLM is not an authentication protocol that's going to help us in this scenario. We then learned a little bit about Kerberos. We learned about its underpinnings and how it works, and how we can leverage this technology to overcome that double hop challenge. We then took a look at the new SQL Server Reporting Services 2012 architecture. We learned that it's now a service application in SharePoint integration mode, and we learned about what that means because it's now implementing the service application framework, in particular SQL Server Reporting Services dependency on the Claims to Windows Token Service. We took a look at how identity and delegation works in SharePoint 2010, and we learned how the Claims to Windows Token Service allows us to transition claims identity back to a Windows token so we can do outbound authentication. We also learned about some of the restrictions with the Claims to Windows Token Service, in particular its inability to delegate across a domain boundary because of the constrained Kerberos delegation that we have to configure. We then took a look at SQL Analysis Services EffectiveUserName option, and we learned about how this option allows us to overcome the challenge of crossing a domain boundary. We then took a look at Reporting Services Data Source files, and we learned how we use a Reporting Services Data Source file to configure the connection to use the EffectiveUserName. And then we finally wrapped up with the BI Semantic Model file, and we looked at how the BI Semantic Model connection works when trying to leverage EffectiveUserName.

Well, that's it, everyone. I've enjoyed our time together, hopefully you have, too. I hope everybody's learned something new about SQL Server 2012. I encourage everyone to go out and download the latest release candidate, and I encourage you to have fun building your BI solutions in your complex environments. Take care.

END