Don't Let Active Directory Hold Back Your Modern Access Strategy

Speaker 1:  Okay, great. We're going to go ahead and kick off the Don't Let Active Directory Hold Back Your Modern Access Strategy track. Sonali is one of our senior sales engineer. She's going to be leading the discussion. We've also got Jay Bruton from the Okta team as well as Frèdèric Poncin from Engie. So, Sonali.

Sonali Vaidya:  Hi everyone, welcome to Oktane 2017. Excited to see this rom almost full, hopefully it will get more full. My name is Sonali Vaidya. I'm a sales engineer with Okta. I've been here about four years, spent pretty much all of my career in identity and access management space. We have an exciting presentation here. I'm going to be your host as well as a co-presenter today. I'll have Jay and Fredrick join me a little bit later. So getting right into it, we're going to talk about your modern access management strategy as it relates to active directory.

Now there are several aspects here I'll discuss when it comes to Okta. But just taking a step back, I would say for years and years active directory really has been the corner stone of access as well as authorization. But mostly traditionally too on prime systems, right? You had your legacy systems, file shares, things like that and active directory provided sign on services to this. 

Of course sometime around the year, I would say 2000, we all start to collectively enter into the world of web 2.0 and then suddenly you have an explosion of web based consumer centric user friendly business as well as social services. Many of this are now offered within the SaaS model, right? So after as a service becomes a thing. And many traditional businesses start to think about transforming into digital businesses. But of course with that shift, the complexity increases as far as your infrastructure goes. Now companies have to think about how do we unwind and consolidate this 20 plus years of infrastructure so that we can serve our customers as well as grow our businesses at the same time.

So to talk about that we'll go with ... we already know our panelists today. I'll talk about a few topics here, and really it's about how Okta helps with that digital transformation journey. But what I did was I picked a few use cases that were relevant to active directory and directory consolidation. So I picked three use cases that directly sort of relate to our subject today. We'll also talk about some implementation timelines. And then of course I would say the cherry on the cake for you guys today is Frèdèric's very, very interesting presentation. You guys are going to love it.

So getting further into this. There was a survey done with IDG very recently. Basically a series of questions were asked to about 58 business executives around their digital business initiatives. And this one specifically was around ranking the priority or prioritization of those initiatives. You can pretty much see from the top three numbers here that the most important thing they talked about was a seamless user experience.

They talked about new customer experiences, building those improving the existing cost employee experiences as well as collaboration with partners. But at the end of the day identity was sort of key and central to this. Of course as you talk to companies that are even larger, these numbers importance was even more. 

So today I mean I'll discuss a few topics here in terms of the use case I'm presenting. How Okta helps with that digital transformation journey. We already know that identity management is central, a key component to consolidating users from different organizations and connecting them to shared applications and giving them access to different resources. Okta enables you to do that. Number one, by helping you build a unified architecture across your identity and access management services and we'll talk more detail on this. 

The second point there is being able to build that shared services layer with Okta. You may have shared applications, you may have certain user data that's unified into a centralized view and administration point but you may still have certain companies that need to be segregated or certain data. Maybe customer data that needs to be segregated. How do you connect all this into a single frame work?

Directory consolidation with Okta, we'll talk more detail on that as we go further. And then of course very important, agility, right? So you're not only connecting users, you're also rolling out applications. You're also making applications available on day one to these new populations of users that are from maybe a new company that was acquired. So we'll talk about that. 

Centralized versus autonomized. This is actually something that came up in my conversations with Frèdèric. Because he talked about how they had the need to centralize a lot of their user data. But globally they still had countries that had regulations where some of the active directories needed to be completely autonomous. No trust, no WAN, no connection to the rest of the organization. Those needed to be kept autonomous. And we'll look at that within the Okta architecture in terms of how we connect those. And security of course again, being able to manage your security while you go through this process. 

So talking about the Okta architecture, I know this slide look complex but ust to simplify it. On the bottom layer, I would say everyone relates to that. Those are really legacy on prime systems and those databases, directories, ERP systems, mainframes in some case most companies have some of these at least. Then of course companies are making their journey to the cloud. So you now have cloud applications. Things like email and HR are also moving to the cloud. Okta helps you best here by connecting everything.

So we have several agents that connect into on prime systems. Specifically there is active directory, Elder app radius agents, right? And these agents connecting to your on prime sources in a secure manner. Okta as a service though supports federating two different applications within the cloud. We support industry standards like  SAML, WS Fed, open ID connect as well as OAuth and we offer all this as a service. So it's very easy not only to connect out of the box applications with Okta but also to connect your customer applications. Also to connect your consumer facing applications that you may have moved into the cloud or web enabled.

Then on the right side we have different ways in which you can onboard your customers maybe there's consumers. You can do registration with social identity. Maybe there are business partners, Okta supports B2B federation. So there's multiple ways in which you can connect external users not just your internal into that same Okta framework. And to the very right is Okta support for adaptive multifactor authentication. Again, that extra layer of security, right? Now not having to worry where are my global users? What type of devices are they coming from? What type of browser? What type of OS? Is it patched? I mean, after a while you could control it a little bit but it become impossible to control it all the time.

So being able to connect security access policies to the identity of the user. Not so much what type of device they are coming from or what the browser is. Talking about mergers and acquisitions today, typically you'll see one of this modules. You'll see companies coming together, certain decisions have to be made on how to consolidate those directories. You may see the case where acquisition AD is migrated into an existing parent AD. Or you may see new greenfield active directory being created from all the different org forests. All hen simply building trust between the active directories at hand. Either way whatever method you choose, one or more, they are all, I would say time consuming and labor intensive. And how do you give access to those new employees on day one while you go through this process.

I don't want to stand up and say that Okta helps you with any of the migration of your AD objects. That process can still continue but Okta does enable you to give day one access to al those employees into a centralized framework and into those shared applications. And the way we do this is by connecting to those active directories that don't have any kind of one, don't have any kind of trust. We connect to the individually with extremely lightweight AD agent. 

Our agent is secure because it doesn't need any firewall changes. It talks outbound to the Okta service. It helps you sync that information from those ADs into a central Okta to give you a view of those user groups as well as group memberships. Now you have a central framework to apply your access policies within Okta to say who has access to what, what geography can they access it from, do I need to apply a second factor of security when they are accessing that particular application. But make sit extremely seamless without the need to actually consolidate and migrate on the back end.

Building that shared service slayer with Okta. This is another use case where again little bit maybe Engie went through this where certain applications were shared in that layer but maybe there are certain AD first that need to be segregated. Now Okta has very flexible deployment models. You can either have one Okta that has all the information and then connect that to your resources but you could also have more than one Okta tenant where those talk to each other and share only the information that you define. And we do this using our Org2Org connector within Okta. And that effectively helps you maintain your security posture there where you can have certain user populations completely segregated and maybe even application integrations that can be segregated in those Oktas. 

The last use case I'll talk about is managing your employee life cycle with Okta. This is again another reason why we make that process of going digital much faster because now you're talking about not only consolidating directories, syncing all that information but also you're talking about downstream applications. We have a connector of more than 5000 applications. They are pre-build integrations and on the left side you'll see we have several integrations to each our systems. This really helps you to bring information from the source. But what I see there is a lot of companies still consider AD as their main source. So being able to use that AD agent to just point to active directory as the master record, sync all that information into Okta and then from Okta to provision into the down stream systems. 

So things like your Office 365, Service Now, Box, Salesforce, these integrations are full life cycle management integrations within Okta. You can provision manage attributes through those integrations but keep in mind that one thing there on the bottom I'll point out is active directory shows up at both ends of that picture. And this is important to note because Okta's AD agent is bidirectional. So not only can you sync information from an existing AD into Okta, you can also use Okta to provision down to a new AD or a greenfield AD. And this is something that a lot of companies have used for M&A activity, for giving access to applications that are integrated to AD and those AD sometimes are separate. There's I mean several use cases there. So Okta helps you sort of close that loop on your life cycle management where when access is terminated in your source system, it can now go down and push those deprovisioning or terminations within the different down streams systems as well. 

With that we will talk a little bit about project and consolidation timelines. I'll actually want Jay to talk about this. Jay has long term experience not just with Okta but with Microsoft. He also works on a lot of implementations with our customers so I think his perspective will be great. Thank you.

Jay Bruton:  Thank you, I'll be very quick here. I've only got a couple of slides but we want to talk about active directory consolidations and what they typically look like when you're doing mergers and acquisitions and that sort of thing. So it's a pre-long project to consolidate or migrate users from one active directory to another. And this you have to go and create a trust, you have to deploy infrastructure, you may need to make a troller across the wind, you need to plan a migration, which takes a few weeks, distant testing, all those types of things. You probably have to clean up the active directory a little bit to make sure the migration goes smoothly. What we're showing here is a typical active directory migration of about four months. I've done a lot of active directory migrations, four months. I probably have seen them at four months but most of the ones that I've worked on were much longer. As long as a year, a year and a half depending on the size of the organizations.

The one thing that we don't talk about or show in this slide is even before you can start this process in a lot of cases with mergers and acquisitions, you have to actually go ahead and acquire when lengths, you have to build firewalls, you have to [inaudible 00:17:24] things well, which extends that time. So typical of an Okta deployment, much shorter. You do some discovery, you figure out what active directory you have out there, you do a little bit of design work, it takes a couple of weeks. You start building out your plans then you put in your active directory agents and within a few weeks you've got a domain integrated. The more important thing is and Frèdèric will talk a lot about this but that two month, three month period is for the first domain but the second domain is probably a week or two. The third domain a week or two. And in Engie's case it was many more than that. So with that I'll turn it over to Frèdèric.

Sonali Vaidya:  Just three, yeah just got three times.

Jay Bruton:  Oh sorry, I didn't realize it wasn't build. Also with Engie we did two weeks per domain to start the consolidation. They had a hundred plus active directory first. They were all consolidated into Okta and then all consolidated into a global active directory as well. We did provisioning for them. It took them six months to roll out as 365 to 120 users across those active directory forest. And there were no WANs in place, no network connectivity, no trust required any of that. And I'll turn it over to Frèdèric.

Frèdèric Poncin:  Thank you. A little question before starting. Please raise your hand the on in the room that did an ID migration already. They've been needing one. Then please raise your hand the one that would like to do it again. Okay, I'm done. Now maybe I should first introduce quickly Engie. What Engie was this company? It's first of all a very large diversified utility company. We are active over the world. A very large amount of employees over 150,000. And we are mainly active in different business. Can be electricity, can be natural gas, can be energy related services. So to give you fifty two examples, maintaining your heating system, it's us. Operating nuclear plants, it's us as well. Operating vessels transporting liquified gas across the ocean we do it as well. Consulting on energy efficiency, that's becoming more and more core business. So those are the kind of activities we are doing all over the globe. And based on the company, which is basically based on merger and acquisitions. It's over one of the years of history people from all over that have been brought together.

Basically two years ago, we added a new impulse, a decision regarding the strategy of the company. We wanted to position the company as the leader in energy transition. This means that we had to solve three main challenges. The first one is to handle decarbonization. We are moving more and more from a fossil scientific energy towards the renewables. The second one is related to decentralization. The time of the big power plant are over. You put solar panels at home, you produce to consume in a very independent way. The third one, the third D is digitalization. Which means basically that if you don't have an app, you're nowhere. But not just for the app, for the acceleration you will provide for the two other D, the decentralization and decarbonization. 

This led us to understand that we needed a new way to pull resources within the company beforehand we could just have silo. The guy doing everything on one side, the tour guides on the other side consulting a separate part and so on and so forth. It was not possible anymore. If we wanted to accelerate, if we wanted to really take advantage of this energy transition, we had to federate all those potential resources. Then came the need and it was really a business need to deploy a collaboration tool. A transversal platform where everybody could interact. And I mean really interact in the sense of Yammer, in the sense of Skype business, in the sense of common share points not just a productivity tool. And we opted for office 365 at that time.

There was a clear urgency in that. At the same time we learned that we would go through a company wide rebranding within six months. So Engie that I'm representing here today, that brand did not exist two years ago. We had hundreds of email domains, hundreds of brands, and we said, "Oh we want to build one company, one brand all to create this kind of atmosphere within the company." So one we looked at the IT systems, at the IT landscape. What did we find?

First of all there's very nice pictures of the Ads. We had over 300 ADs all around in some ways connected at a trust here, trust there, we did not really know how many we have. But that was the current landscape. We had to move away from that. And I'm pretty sure that you know if you have 300 Ads and you want to start and AD migration project, you run away. So we had to find another way. We had to find a way, which could still key the existing environment and leverage it. And at the same time make changes also on the organizational side. People we used to work in silo. Here we needed to have a central idea interacting with all these distilleries and create this kind of coalition platform. 

That's where we had to look at the market and we made the very quick due diligence. I will give you here a very brief understanding of the mindset we had at the time. The first thing we did was really a realities check. What was the status? We knew that within six months we have to do the rebranding. So what could we do? We had resource forest with over 100,000 mail boxes, account forest on the side with some trust. Then we had plenty of ADs all around that sis not even have network connectivity, entities that we're subject from merger acquisitions and they were happy with their lives there on the side.

Furthermore those ADs they had been build over 20 years. Meaning that routable UPN, that accounts did not exist for some of them when we build those. So [inaudible 00:25:18] will tell you, we need your table repair and you say, "come on, You want me to reinstall it? Not possible." It's even worse than that when you look at the worst issues, so many subsidiaries, so many masters, I'm calling that zoo, you name it, we have it. Windows XP, Vista, 2000, 2003, 2008, Windows 7, we have it all. Same for Office, same for the browsers. 

This with all potential patch levels, so we had to do something, which was sufficiently lightweight to go live. Then if you look at the AD themselves. You say, "Oh, an AD is an AD." Not really. Each of those anti-D decided oh I need my own schemer. So you couldn't even say I will apply the same mapping everywhere. No way. Then you have another look, you say, "Oh we decided to use Office 365." Good news. But then you look at the specs, and you say, "Oh Microsoft assumes that the UPN equals the SIP address and equals STP." Very bad news. We knee that we were in the middle of a rebranding meaning that all the SSTP address would change. So that equation would not work.

Furthermore we also had a little constraint. We had accounts made of single point of provisioning. You have AAD in the cloud, if you want to push identities in there, you're supposed to only do it from one point. Here we did not have an internal network for doing that. So we had a quick look, we tested the bet and then we turn to act up and Jay especially. So then came the design and that one was a very quick one. We had to make choices. As I mentioned it was a collaboration platform. We had to deploy internet, Skype, Yammer. We were not there for deploying each relies on with the Excel and the Word, that was not the point. So we were willing to start small. Let's start with internet. Anyway, if it's not working we can always put it on premise. Let's try with that.

Then you look at email. There if you look at the time for migration project, it takes year. The only option we had was if we wanted to go to the cloud at the end, wants to say, "Oh let's go over the change and we will progressively migrate mailbox from on prime to the cloud. The decision regarding Skype was a bit different. In fact Skype is not really a business critical application. We could switch it off two weeks, we configure and then switch it on again. And that's exactly what we did. 

Then came the more technical decisions. Office 365 has specific requirement regarding a set of fields. What should be the imitable ID? Basically that's the identity of the user. Recommendation from Microsoft would be, "Oh please use the SID from the active directory." But we knew that all active directory were just a mess so if we started relying on the SID, the next day we would stop with the migration, we would be bad. No way. Unfortunately, we had some kind of matriculation system for employees in the company. Basically giving an identifier for all employees from the cradle to the grave. So that was what was really unique and we decided to use that one. 

The point is that if you want to deploy rich clients, and this was two years ago, the Skype, the Outlook. At the time we had two options, either we use the good old authentication mechanism valid for Office 2007, 2008 or we were jumping to modern authentication. We took that leap of faith. It required a lot of testing because it was really not that stable at that time but now we are very happy with it because it gives consistent user experience for everyone. 

Then came the design. Worth mentioning that we needed hybrid change so this brought one additional requirement. We had to use AD connect because that is basically the only option you have to synchronize on premise identities with cloud identities onto Microsoft side. It's up and done from on prime to the cloud and from cloud to on prime and keep being updated. Not only for use object but for the room, for the contact and everything. 

So that being done, choice being made, we have to face the risk. What were the risk? First of all it was a big unknown. We looked around, we tried to find another company that already did it. We could not find one. Not at scale at least. The second is find the support. We turned to Microsoft, we told them how we have this nice idea of using Microsoft as IDP for Office 365 and they told us, "Guys are you sure?" And then we understood clearly that was not basically the best way to get support from Microsoft. 

We were still facing the time constraint We had to go live in six months or no. When we decided for Okta in three months. So we went all in basically and we started running. Regarding the organizational model there we had to put in place some kind of delegation mechanism. We handled that. And finally the last risk we had was related to data quality. Look at 20 years old AD, what do you find in there? 

We have ADs with 10,000 users and over 10,000 groups. You don't want to bring the crap from on prime to the cloud. You want to start clean. So we had to find a scheme where we would have something, which is manageable cloud site. So mitigation. We did plenty, plenty of testing. We started small, we started with intranet only. We also defined what we called technical driving holes. Basically that's a technical contract between local subsidiary and central IT. We tell them, "Guys if you apply this kind of GPO with this kind of proxy on this work station, it will work. If you auto scrap, no chance." And then we turn to Okta provisional services and asked for commitment. 

There we were in October and we knew that we were going to go live on January first. That's where Jay was ever involved in the design and the set up and that was really key in this exercise. And we keep doing this kind of technology deep dive. Because you start with integration intranet and then this opened plenty of options. 

We also decided to have a model, which was as loosely coupled as possible. We have ADs on one side, we have apps current application on the other side, we have Okta in the middle. Let's avoid to have things too deeply coupled because we know we have the AD today if we could simplify young premise the sooner the better but we don't know when. So to give you and idea of what kind of journey did we have?

Basically, spring time 2015 we had a business decision. By summer we launch the project with a budget. By October, we decided to go with Okta and January first we went live. We went live with 50 ADs, 100,000 employees in there and one application, Office 365 and one usage, the intranet with desktop SSO. Two weeks later we could relaunch Skype, that was an easy one. Two months later, we went all in with self service for cyclone connections. And a user could ask for one same time we reshaped the Yammer network. We had hundreds of email domains. We wanted to have one network to facilitate collaboration and there we had to clean it up before relaunching it. 

Basically at that point, it was done. It was a success. It took a couple of more months to add more ADs and yet we moved in six months from 50 ADs to 100. From 100000 employees to 160, 80, 70, 80 it depends how you count. If you count employee, a contractor whatever but actually we could say to the application on this we are feature complete. Whole users are in the Okta universal directory. If you want to connect an application, if the user is missing or fault, don't worry it will be there. At that point we thought, "Oh this is over, this is good. This is fine." Then came the second part of the digital initiative. We have the launch of Engie digital. That's where the company decided to go mobile. To build digital platforms. And when you go mobile suddenly you face openly connect. You want to put a mobile back end in place. You want to have an API gateway in place and link all this with Okta. 

That kept us busy during last summer. But it was a success. Autumn came then we found out that more and more employees were storing confidential information on share point. It was time to deploy MFA. First we deployed it for a limited scope, a couple of thousand users. At least we were protecting the most critical information. By the end of the year, we could just say, "Oh yeah, we have a run model. It's not project mode, it's purely a run." We knew as a routine change, had to remove an AD. Add one or two application a week. That becomes something normal to do. And that explains that. Yeah, it takes maybe two weeks to connect an AD but maybe even less for an application. It turn very easy. And we kept adding features.

January was the month of rage for VPN. The around April we had B2B tenants and we started deploying another instance specifically for business customers. Then came cloud accounts. If you have blue collar workers, that basically maybe need access to email in the cloud, why would they need to exist in the on premise active directory? It doesn't makes sense, it's just consuming licenses. And very recently we just decommissioned the last pieces of the ADFS on premise. So where are we today? Today we have over 100 applications connected. We have over 100,000 users and four MFA meaning that if they want to connect from outside of the intranet network they will be prompted for enrollment and out of those we have 25000 other actually enrolled.

And we can say starting now adding new features coming from Microsoft bit, teams, Skype PBH and so on and so forth will increamitive features that will come on the platform. What I mentioned is that after six months, we had basically covered all the Ads. This also means that starting from there we could start looking at AD migration. We could progressively start to clean up the mess moving users from AD to AD decommissioning old Ads without affecting much house. Same for exchange online. Worth mentioning, hybrid change, we started with the exchange still on premise. We started with hybrid and then we are progressively moving mail boxes from on prime to the cloud.And this is something that can go in part with the rest. We just hope that basically in one year time, we can say, "Okay, everything is moved, everything is migrated let's simplify the model."

So just to give you an idea, what did we put in place from architectural standpoint? It was mainly a many to one to many model. As many AD as we want one Okta tenant and ask many applications, one of them being Office 365. And one given name space in the middle. We took the opportunity to rename all those, identify you and have a clean name space. Meaning that we move user from AD to AD no impact cloud site. How does it work from a provisioning or authentication standpoint?

Authentication is that easy. Application to Okta, Okta delegated authentication to AD, nothing new there. Provisioning was a bit more tricky. I mentioned we have this resource forest and this account forest. Resource forest hosting all the email boxes and so on and so forth. We had no network with some Ads. So what's with it is that we are provisioning from remote AD to Okta and from Okta to the resource forest. Therefore, we have whole identities there on premise and we can consume AD connect to push all this to AAD. Spoken fairly well, I'm happy with it and this really allows us to progress to the migrate all old mail boxes from on prime to the cloud without any other dependencies.

This is really much about agility. We have here a model where we can in parallel launch email migration from on prime to the cloud from a remote mail system to exchange online. At the same time we can migrate users from active directory to active directory. We can add applications. We can help user move from one cabinet to the other in mobility context. All this in parallel mainly driven by the local entities. We are not the bottom neck anymore. 

From an organizational standpoint, what do we have? We are mainly on one side the corporate program. All the heavy lifting performed by the project. We have as well the IT subsidiary, which was mainly there for the run second level support adding application and so on and so forth. And on the other side, we had over 100 local IT, 100 Service desk, more than 100 application owners and we needed a link buff ranker in the middle. A common grounds, a common understanding of what had to be done for this to work. And we defined a set of typical artifacts. The first one I mentioned was the technical joining rules. It's very technical, very detailed but is basically the technical contract between the central IT and the local IT. If you do that it will work.

The second part is to enable the local IT. An adaption dashboard, a data quality dashboard allowing them to understand what's the current quality in the tenant. Okta's side but also Office 365's side. We also needed some kind of delegation tools. We did not want to grant access to Okta to all the local IT. We did not want to grant access to Office 365 or any sort of purpose to the all the local IT. So there we had to quote some sort of delegation mechanism in the middle. 

And finally all kind of operational guide to support all this. To give you an example, that's the kind of panel we've build the adaption dashboard, this is for MFA and we can reel down. A local IT will have access to his whole user population, we'll see what the current ramp up, which kind of users have been already enrolled, which one are not and they can just be in control. 

Going back to the initial question and the topic of the talk, what do we plan to do with ADs? This big mess we have there. Well, we still plan to progressively move towards one forest, multiple domains model, progressively. No hurry in fact. And the same for mergers and acquisitions. You face a merger and acquisition situation, the guy in front they don't know you, you don't know them, they don't trust you. So if you just tell them oh put an AD agent, with just this part you will get access to the collaboration platform, this is bringing trust, this is very easy. Then later on we can, if needed, bring them in. Put them in the common forest. And it will be done over time.

But once we relieve the pressure on the time constraint, it will also lower the cost. It depends on opportunity. If you're up to trying something here, let's move anyway. That's really helping with adaption. The other question or the other topic was related to governance and we really want people to put things in place. On one side we have this one tenant for all employees. That's nice, that's working pretty well. We considered that this is basically a corporate object. It has to be managed by corporate for all employees over the company. 

On the other side we have things that are much more related to the local business processes if you think about B2B who will be in control of the local partners? That's not corporate, that's the local subsidiary. There we considered that it should be one tenant operated by the local subsidiary that can support those kind of initiatives and we can just bundle them together putting some kind of Org2Org interaction allowing employees to stumble in seamlessly and that's a model we are already pushing around the local IT.

So just to give a final point, yeah, we collected plenty of applications. This is just a little sampling and in fact the best thing we have is Okta today. It's that it's so use friendly that is the best way to avoid shadow IT. If you start buying your staff application, putting it in there, as an application in there as an application owner, you have to manage to log in the passwords. Your users today they don't want to handle more passwords. One is enough. So they come to the Okta team and they just say, "Oh guys could you work this cross mode application?" And in this way we progressively get more and more knowledge of what we have around.

Example, Asia, plenty of subscription. Salesforce, oh multiple of subscriptions and so on and so forth. So when starting this dialogue with the local IT we are progressively bringing all this in shape and getting a better understanding of what's the IT within the organization. And that's it for me for today. So what's the time?

Sonali Vaidya:  Thank you. I know we are over on time. We were going to take questions but I think we'll all be outside if anyone wants to come up and chat. We're outside since our time is up, happy to anyone. Thank you guys. Thank you so much.