Streamline your Identity Governance and Administration – with Microsoft - 27 September 2023

Chris Howett: Perfect, right cool. Okay, so when we talk about the joiners/movers/leavers process, I'm going to put this into what I've called the Four As of the joiners/movers/leavers process when we come to do it in the Microsoft world, and the first one is automation. And what we want to try and do is automation as much as we can do, the less manual we can make this process the better but also, yes, whilst you reduce human error but obviously reduce workloads that actually have to go into actually managing the process in the first place as well. But there has to be an acceptance, in today's world we can never fully automation the joiners/movers/leavers process. People wear too many gaps, it's just the nature of public sector let alone, well, most other organisations for that matter as well. Once people have been around for a little while they may wear multiple gaps, so somebody might come in doing finance and as they work through finance they might then move to HR but they may either move out of finance entirely or, most likely, they're going to maintain finance responsibilities, so they need to be able to sit in both camps of what we want to do. So, what we then then look at is autonomy, and we want to put some bits out to the business. And if we try and manage the joiners/movers/leavers process, and I use this term of empires and kingdoms, if we as IT then try and manage everything as an empire it becomes very fragile as scale because there's only so many people who can actually go out and do so many things, there's no way that everybody can know what everyone in the organisation does so it becomes very difficult to sort out. Also, typically when requests come in, even for automation or just for approvals, or whatever else as well, the first thing IT is going to do is go back (audio cuts out 04.40-04.59)-, but with that autonomy we can say when we talk about these kingdoms, a kingdom is effectively a business area, so let's say it's finance, it's HR, it's child welfare, whatever, pick your business area and what you want to call that. And what we can allow people to do is have some degree of control over their kingdom, so we have delegates within the kingdom, whoever else that may be, to say, 'Okay, yes, I give this approval. Yes, I actually allow this.' And with that we have accountability, so 'Why did I grant this person access? For what reason and for how long?' Etc, as well. So we have all of that and an audit trail of what's actually been allowed. Even if that's allow indefinite access. But what we can also then do is have attestation to say, 'Well, great, we've allowed somebody in but do we want to allow people to maintain access?' So, it could be a month, it could be quarterly, it could be half yearly, yearly and weekly if you wanted to to say, 'Right, should people actually maintain access to these resources?'

So you can then go back to the delegates within the kingdom and say, 'Right, actually, is this correct?' And they can go down the list and go, 'Yes, I'm sure all these people should have access' and go, 'Yes, yes, no, yes, no, yes. Actually, I'm not sure about this person, I can now request attestation. Why do you still need access?' 'Yes, I've moved out of finance into HR but I'm still doing a handover so I need access to the finance pieces so I can train up the next person. If you ask me in a month's time I probably won't need access and it'll all be done.' And if (audio distorts 06.27), 'Oh, I need it for an extra week' or whatever else as well, but then you've actually got that accountability and attestation as to why somebody's got access to resources and that side of things. But again, the majority of this is going to be automated, okay? Cool. If there's any questions or anything please feel free just to put up your hands as well, if not we can save questions till the end. So, building out a diagram and going into bits and pieces and now, what we have to actually start making this possible is something that's new. So, this is what we call the Entra inbound provisioning API, (audio distorts 06.55). This is new, it's currently in previews, and this is what actually is one of the main bits to facilitate this. So, one of the major problems with us being in the joiners/movers/leavers process before is there has to be a single version of truth of who's in your directory, so that's typically your HR system or something along those kind of lines. And there never is a single version of truth because you could say, 'Well, this is what we've got for our full-time employees but this is what we have for contractors, our contractors aren't actually in our HR system, we bring them in for a different reason.' It could be we've got some front-line workers, you know, like the lollipop people or bin collectors, or something along those kind of lines, that may not actually be in the system at all because they're there, they might get paid and they might be in the payroll system but not in the HR system, or something along those lines to work out. So, what the inbound provisioning API allows is to do now is take data from any source and multiple sources at the same time. And what the inbound provisioning API effectively is is a SCIM input, so S-C-I-M, so it's an open standard for identify management, basically. So, there'd be maybe bits that may sit in the front of the API, such as a Logic App or whatever else as well, so it's like, 'Okay, if I've got a CSV file that I've just exported from iTrent' or something along those kind of lines, and pick your HR system that might be used in a council, we can have a CSV output, we convert that CSV output, all automatically, into a JSON format which the Entra, the provisioning API can then sort out. With that, we can then provision the user and we can go onto on-prem, and I'll go into that in just a moment, and we can put that into Azure AD, now rebranded to Microsoft Entra ID. So if you see Microsoft Entra ID we're talking about Azure Active Directory, all the same thing just a different brand.

So, once a user's actually there we can then say, 'Okay, well, now we can start managing what the user has access to,' and this is where the entitlement management piece comes in. And this says, 'Okay, well yes, theses are all the resources that we have for finance,' or if we talk about that empires and kingdoms, the entitlement management allows us to define what's in a kingdom, these are the resources that are allocated to a kingdom. So, for the finance people, they can have SharePoint sites, groups, teams, you know, cloud applications, can have on-premise applications, all that kind of good stuff can all be pulled together into the entitlement package, and then we have those controls that go around that.So this is just a simple piece but then we have the new bit which is the lifecycle workflows. I will say this does sit just beyond D5, in an extra license called the identity governance skew, but this is where we've got our automations and we can start managing workflows for joiners/movers/leavers processes, and again I'll show you what that looks like. And of course, at the end of the lifecycle the user is removed. So, we go in and start building out a little bit of detail here, what we can have with the inbound provisioning API is actually a connector. So when we configure the API we can actually have multiple API endpoints for this, and we can have one that goes directly to or we can have one that goes directly (TC 00:10:00) to Active Directory, we can have both if we wanted to, depending on how you're configuring it, and where you're taking inputs from, and how you need to configure the user and what kind of controls you have. Example being, when we get to the lifecycle workflows we rely on, currently, an attribute within Microsoft Entra ID to have what we call the employee hire date, and we can get that directly from an HR system or from an import, or whatever else as well, and that's a native attribute in Azure AD, but it's not an attribute in active director. So we can do a whole bunch of mappings and controls, via the on-premise connector and the inbound provisioning API we can configure this attribute that comes in from the CVS file actually writes to this attribute on-prem, and then when we actually sync up that attribute on-prem actually eventually goes to the employee hire date. Or we can have the user provision directly into Azure AD to start off with, that has that information, and run the same cycle just a few moments later that also provision is to on-prem. So it's got these extra details, and when they then synchronise it merges the account together, so you then have a single user account that has all these attributes start pulling together that can come from multiple sources, and we can pull them together in a very simple way. And again you then have the synchronisation that comes on-prem etc, as well.

And then what we then have with the entitlement management is that we can have our Microsoft 365 groups and teams, as I said, our SharePoint sites, third-party apps etc, and these are all the cloud native stuff, basically, and we can pull that in. And they have to be hooked up into Entra ID to start off with, and obviously SharePoint and teams is natively integrated anyway, but we can pull all of that together. And what we can also do is pull applications from on-premise is well. And what we have originally was what's called the Entra app proxy or the Azure AD application proxy, and with that we could publish applications over 443 only, so a web interface, basically. And we could present that out as a cloud application or what we call an enterprise application which we could then present into Azure AD, protect it with conditional access etc as well, but also wrap it into the entitlement management. Now, what we're just bringing out now, it's currently in public previews and you can access this in your (mw 12.13) today if you go to entra.microsoft.com, we now have what we call global secure access and then that's broken into 2 components of private access and internet access. Internet access, only a few bits are in public preview, most of it's in private preview at the moment, that's coming soon, but with the Entra private access what we can then do is publish any application currently on TCP only, UDP is coming, but anything that we want to as an enterprise application. So, we can say, 'We want to publish this FQDN, i.e. back access file server, on port 445, so that means that we can publish SMB file shares as an enterprise application. We can then protect that with Azure AD, with conditional access, and conditional access now integrates network controls because of this as well. And bring all of that in to say, 'Yes, this is definitely the right person who should be accessing these resources,' and pull that in, so we can then say, 'Right, everything that's in the kingdom we can pull together,' and I mean everything for on-prem and cloud. And where on-prem, that could just be your remote data centre, i.e. not posted as a SaaS or a PaaS app, basically, but these are all your IaaS apps or potentially PAS apps as well, there might be an overlap there. So it could be Azure file shares you want to put through here as well, when you want to have authentication to on-prem, you know, directly to Active Directory for your Azure file shares and do Kerberos authentication. Great, we can publish all those components and all the ports that's actually required for the app, and put that together as a single application, as far as the end user's concerned, but it can access all the resources that's actually required on there. No VPN at all, no inbound ports at all as well, so full access to whatever services you actually need. Then of course we've got the access reviews that back this up, and the access reviews are what allow us to go, 'Okay, well, nothing fits in there so we now need that,' or the autonomy, accountability and attestation.

And this comes via the access reviews which, in turn, ties into the entitlement management. So, when we create this package we can say, 'This is a package for finance.' When somebody requests the finance package a delegate within finance, and that could be delegates plural, it could be a group, it could be a static person, however you want to define that, to say, 'Okay, yes, do you approve that this person has access and why do you approve it?' All of the attestation is optional but you can put all of that in place, you don't necessarily have to require approval, depending what it is, somebody simply has to request it to actually do that. And there might be an access. Review to back that up to say, 'Should people be maintaining access to it?' And that's when the delegate steps in to say, 'I'm going to kick somebody out of that group.' So all and well good adding them in but we've got to kick them out as well. And that attestation goes when they give the access review and can say, first off, as a very basic machine learning we can go, 'Well, this account hasn't signed in for more than 30 days, do you just want to kick them out of the group?' That hasn't disabled the account, it hasn't removed them, it's simply removed their permission, so if that account is ever compromised it can't access anything. And what we can also do, it comes along with the lifecycle workflows and the identity governance skew, is what we call user-to-group affiliation, and this is when we can actually do some proper AI machine learning to understand your org chart and the kind of resources that people access. So, for example, if we look at finance, and picking on the finance department, so we can go, 'Yes, these are all the resources that finance have, these are the people in the finance department. We can link them together with their managers, and these might be the people that overlap,' you know, there might be finance and HR might work very closely together, whatever else as well. Now, let's say a social worker requests access to the finance resources. Now, from the org chart perspective they're probably miles away from finance, which means when they go to access those finance resources we can go, 'Well, no other a social worker or people from that side of the business actually access finance resources,' so when somebody makes that request is that actually legitimate? So, we can go to that and say, 'Actually, the affiliation for that request is very low so we don't recommend that you approve that and we give it a low affiliation. And we could then have that attestation going, 'Well, why do you need access? Give me some extra information there, give me some justification,' maybe go and ask that person's line manager what they're actually doing, whatever else as well. But we make sure we've got that separation of duties. And I mean a true separation of duties to make sure there isn't a bleed, then there isn't too much, or there isn't somebody requesting access when they shouldn't be requesting access, might have been accidental, the account might be compromised, it could be something in between.

So you guys get enough information to work that out and make an informed decision. And then when we've actually got there, so we then actually have the lifecycle workflows that can kick in. So those workflows, when they come that might be triggered to say, 'Okay, well, we know the employee's going to be starting, we've created them in the HR system,' or whatever else as well, 'but they're starting in 2 weeks or 3 weeks,' or whatever else as well, you've done your due diligence and got them created, effectively, and that's an automated process. So we can then say, 'Pick a number 7 days before they start,' once the account's actually been spooled up we can do a bunch of configuration around that to say, 'Your new employee's going to be starting soon, please make sure you have any ready materials,' or whatever you want to have in that user communication. We can actually have that that they actually request an entitlement package, so rather than the user coming in and having to do that request themselves that request has already gone off and the delegated approval's already in place, and all the rest as well, and the user has access to the appropriate resources. Other side, when they're provisioned they're not provisioned with any credentials, yes, the account is created but they're purposely not given any credentials so there's nothing just sat there for people to be able to access or whatever else as well, the account is effectively unusable until credentials are given. And what, at that point, happens is, say, the day before or maybe on the day that they're actually due to arrive a temporary access password is generated for them, and that's an E3 feature as well, or even a free feature in fact, but the temporary access password is generated for them. And that might be sent to the line manager or to, pick a person that's relevant for that role, because you can have as many in lifecycle workflows as you like and you say, 'This is one for finance, this is one for HR, this is the general one that we have,' or whatever else as well. But we can take that manager attribute, which would have been defined via the inbound provisioning API etc as well, in your configuration, and say, 'Okay, we've given that temporary access password, a temporary access password is seen as an MFA sign in because it's so short-lived. And it might have timeline of, say, 8 hours, may be realistic on day 1, it might have a lifetime of only an hour depending on how you want to operate on that side. And at that point the user can then use that to enrol into MFA and then roll into self-service password reset. So, no additional credentials, no additional hoops or whatever else they actually have to jump through, they've validated that it is that user, it is your new employee etc as well. So at that point, so once they enrol into self-service password reset they can then define their own credentials, which is written to Azure AD and written to your on-premise Active Directory if you want to keep that in play as well. And now, depending on the lifecycle, these people might be cloud only because they could be, again, your bin collectors or something like that as well and you might have given them an account purely to give them a front-line worker or something like that as well, so they've got access just to email or whatever else it might be. So at that point we don't want to provision them on-prem and we can have that in the separate lifecycle workflow. So lots of good stuff as well. And then finally, via the lifecycle workflows we can also kick off custom tasks. And these are basically logic apps, as well as other-, the fine parts that we might have in that. And that might be, 'Add to group membership,' yes? And then, by adding them to a group, that also then assigns them a licence, and the appropriate licence for their account. It could be, it's part of the mover's process in here as well and the entitlement of management. They get (TC 00:20:00) added to a project and for that project, they might need Visio or Microsoft Project, as in, quite expensive licences, to be able to use for that. And once the project is done and they're off that project and on to something else, at that point, we can take them out of the group as part of the lifecycle workflow in that mover's process and say, 'Right, the project is now done. We now pull back that licence automatically.' You know, and all those kind of controls. We can have in front of the inbound provisioning API Azure integration and all the Azure integration services that go with that.

So we can tie in to pretty much anything you want, you know, as long as you can get it to talk to Azure. So we can say, 'Well, actually, as part of that inbound provisioning, when the user is created and they're in x, y, z as well, then we're going to initiate a request for an end-user computer device and we're going to automatically record the serial numbers and the device type and all that kind of good stuff as well as part of that request, and then that can also then kick off an autopilot configuration based on their group. So the device's provision, the device is given to the user, and it could be an app or whatever else as well. But most importantly, when that user leaves, you've got an inventory already built that associated hardware to that user. So when the user leaves, you can go, 'Yes, actually, it's not that we don't know what they don't have and we've just lost 400 devices this year, because we don't know where they've gone because it hasn't been properly recorded,' or whatever else as well. We can now have that all automated in, to say, 'Actually, now done,' as an automated lifecycle, going, 'Please return these devices,' and whatever legal you want to put with that as well. You know, to actually pull all of that together. So we can do pretty much anything you want to have on that site. So this, in a nutshell, would be, you know, what we can do with the joiners, movers, leavers process, which is pretty much anything. Yes, you said there were some features to what-just to call out, therefore, what Paul's' put in. So this feature is in preview at the moment. Odds are, it would be Azure AD Premium P1, which would sit in E3. We will let you know when that actually happens, but that's currently what it's looking like at the moment. Entra ID, obviously, that can be E3, whatever else as well. As far as we're concerned, we can use the free features of what we need to do here. But ideally, Azure AD Premium P1. Entitlement management is Azure AD Premium P2. We're now going into the E5 features on this side to take a look at that. And then, the access reviews and the attestation, the delegate approvals, that all sits as part of the entitlement management and other controls that go with that as well. The Azure AD app proxy sits within E3. So we have that controls to tie on that side, so we can create those enterprise applications. Now the bits that sit beyond E5, or the plus piece, are the lifecycle workflows. And this is what we call the Entra identity governance queue. But it's absolutely essential and we're talking about, at the moment-, and this is hearsay at the moment, because it's still very early days, we're trying to get that included in DTA 24, so we can offer you some really good pricing on that.

We will let you know when that happens. We are literally in the very early phases of negotiation on that. But we've put it back to say, 'Right, we think everybody in public sector needs this,' and I mean everybody in public sector. So we've put that forward as one of the things to have a sensible level of discount, you know, as normally in the DTA agreement. As I said, that is very early days, no guarantees, just really caveating on the call. So with that as well-, so that will then sit-, the user's group affiliation. We can call it 'AI access reviews' or whatever else as well. So then sit in the identity governance queue. There is a bolt-on price if you've got E3, and then there is a lower bolt-on price if you've got E5, because it adds E5 features as well, if you don't have that. And then finally, the Entra private access. That will be a separate licence. We don't know what that is going to look like yet. We will know in the next month or 2 what that will actually be, but private access, we've been told by our product group, will be a separate licence. That's as much information as we've got right now today, because it's still in previews and we're working out what that's going to look like based on previews and customer response and things along those kind of lines. So we'll have that information in the next month or 2, hopefully, give or take. By the end of the year, let's be realistic, by the end of the year, we should have that information and be able to give you that, where that sits. And as I said, the Entra private access is part of our 'Zero Trust networking,' as we call global secure access, which is basically our security service edge or SASE, or whatever you want to call that. It sits in that offering there. Before I go into some demos to show you what this kind of stuff can potentially look like, are there any questions?

Aaron: Just a summary from me. A couple of questions in the chat around licence types and that sort of thing, which I think you've covered and I've put some comments in the chat as well, so I think that's all covered. Any more questions on licensing, please let us know. We're happy to talk through them now.

Chris Howett: Yes. I appreciate some of this is extra, but, as I said, there is a lot of compute and lots of bits and pieces that go on the back end to actually make this kind of stuff work. It's a lot of resource on our side. The reason we haven't put this into additional licences is because we don't want to have to increase the cost of existing licences, you know, any more above inflation or anything along those kind of lines as well. Yes, so these are-, I'm not sure they are going to be specific education SKUs to go with these as well, or educational licensing, but there will no doubt by the usual education discounts that go with this as well. So as I said, these entry features and all the rest as well will just be a feature of Azure AD, and you'll get that kind of functionality on that. The entitlement management would fit in the A5 SKUs as well. It is also worth noting that the entitlement management pieces can also sit with what we call 'External identities.' For those who are not familiar with the term, 'External identities' is what we refer to when we talk about B2B and things along those kind of lines, as well as B2C. But most importantly from a licensing perspective, we have what we call the 'Monthly active users' billing model, the MAU billing model, or however you want to do that. And what the MAU billing model says is that if you've got 50,000 guests, that 5 0 k guests, unique guests each month, as in uniquely signing in and active guests each month, to be really specific on that, they are completely free. And you can say, 'Actually, all these guests actually come in at Azure AD Premium P2 level,' so we can use these entitlement management features. So we can use, kind of, this bit off the map here. You know, all of that as well. The only bit we'll be missing is the user-to-group affiliation and then these bits on the side, basically, which is then the lifecycle workflows. But we can take advantage of all that kind of functionality for your external users as well, which means you can group them together and give them those kind of controls. You know, and they could actually, say-, well, rather than them being provisioned into your directory or whatever else as well, they might actually come in as a guest and then you actually assign controls and all the rest actually to them as a guest, and that might be slightly more manual. Or the guest actually has to request access themselves. And as part of the entitlement management, we can do something called 'Connected organizations.' And that then says if you've got a trusted organisation, as in, you know, there is a memorandum of understanding and maybe some legals or whatever between the 2 of you-, to say, 'Yes, actually I trust this organisation or this domain, therefore, this tenant.' To say, 'Actually, yes, when I create an entitlement management here, I can present it into their tenant.' I can have my conditional access controls as saying, 'I require a compliant device, etc,' as well, applied to their tenant as well.

And I can take that device trust and the device claim and the MFA claim from the other tenant into mine and say, 'Yes, I agree. You are on a managed device. You can access these resources.' So there are lots and lots of good controls that we can put in around here. Okay? If there are no questions, I will dive into demo, so you can get an idea of what this actually looked like and what I needed to do to get this set up. So feel free to keep firing away. I've got you open another one and Aaron can prod me if there are any other questions that come up. So if we come out of this, what I've done-, in an Enterprise application, if I go to 'Create a new application' here and I look for 'API-driven,' I've got the 2 new API endpoints. And you can see there is one for 'Active Directory,' so for Entra ID or Azure Active Directory. And then there is one for on-premise Active Directory. And I can have both of these. It's not a problem. You know, there are no issues on that side. And then once I've actually got those created, and in true Blue Peter fashion here are ones I created earlier-, sorry, are there any questions there? Okay. So what I've done-, when I created this, there are guides online on what to do to get this set up. But I had to assign some permissions to it. That was the first thing I had to do. Some of those, I had to assign via PowerShell, some I can assign directly in the GUI. And I actually have to do both, depending on what you're doing. So first off in the GUI here, I can assign the permissions. That one is not actually required, but I was playing around and figuring this out. But the synchronised data user upload and this AuditLog.Read.All, so we can actually write into the AuditLog or read what has actually happened on the back of this, they are the essential ones that actually need to be given. And what you can then have is, if you have a Logic App or whatever else as well that is actually firing off to this API, you're going to need to grant permissions to the managed account or the managed identity that reads into the API, so it can grant access to actually create accounts and do whatever else as well. But that is where the 2 permissions and that lot are going to be required. The most important thing that is going to be in place is this provisioning and how we present this provisioning out. So hopefully that's going to read in. So what I can do is, once I've created this, I will get an API endpoint for my upload. So this what I'm going to have. Any Logic App or any SCIM application or whatever else as well, this is my endpoint.

This is your entrance into your directory or my entrance (TC 00:30:00) into my directory, to be able to access the actual endpoint. So that would be unique to yourself and unique to your tenant, and basically tied to that application, basically tied to a GUI etc as well. A bunch of job IDs as well. That's more for when you're looking into logs to find out what has actually happened. And if you've got multiple endpoints, as in, say, one for Active Directory and one for Entra ID, you might want to know which job ID and, you know, which one it's actually referring to, if something is not working or gone wrong or whatever else as well. And then the most important part of this as well, once I've actually started the provisioning, is to map my attributes. So you're going to have to have some mappings, some SCIM mappings. You need to familiarise yourself a bit with SCIM, and this is probably going to be the most complicated bit. But most of this is going to be out of the box, and then you can tweak this to your heart's content in terms of what you want to add in. So I can say in my advance mappings, 'These are the attributes that they actually care about.' So when this comes up, these are all the attributes that I can take in the SCIM format. And I can add my own attributes as well if I want to. So I can configure this directly in the GUI, or if I'm doing this en masse, I can do it via PowerShell. And that then grants access and allows you to say, 'Right, yes, this is what attribute we actually want to come in, what kind of format it is coming in, or whatever else as well. And most importantly, we have this primary key. And this primary key basically says, of all of them-, so you have multiple endpoints and multiple different ways of actually building the user together. This has to exist from all your sources. This has to be the one attribute that exists in the whole lot of them. And that is what is going to basically say, 'Right, actually, we know which identity we're now talking about and which one is going to be either created or updated,' basically, or removed, for that matter, as well, and what kind of controls you've got in that. Okay? So I just close that one off, because I don't want to modify that. I can also then attribute what goes on PRIME. So I can say, 'Well, what attribute am I taking from my SCIM source that then maps to what on-premise Active Directory attribute as well.' But that basically then allows me to do that individual mapping. And with that, we can have, you know, what is coming from where to where, basically, so what attribute we are actually putting in here. So you can now add your own custom attributes in there as well if you wanted to. So as an example, I've added the MSTS cloud extension attribute one. I could also use the standard extension attributes, you know, your normal 15. I've got 20 cloud extension attributes, so that gives me, like, 35 attributes I can play around with that are existing, that I can use to map one thing into another, to have some control.

So this is the more devvy, techy side, whatever else as well you want to basically get your configurations set up with. What I then have once I've got all my mappings and my provisioning actually started and the provisioning actually up and running-, I now need something to call upon this provisioning API. So what I have here is-, I've created a logic app that is going to do the call for me. And what that logic app is actually doing for the purposes of this demo is-, I've created an Azure file share, and I've put that-, I've then created a container that contains an SFTP server that then allows me to basically call upon-, I can dump a CSV file in, basically. And that allows me to actually use, you know, remote services or automated services to manually update that CSV file via SFTP or whatever else as well. And all of that sits in that storage account, just so you are aware of what is happening at the back end. But the real magic sits in this logic app. This logic app, you can get off GitHub. Please don't try and write it yourself. It is quite complicated. Good luck if you've got the skills to do it, fantastic. If not, you can just download if off GitHub. And the other component that sits within my container is a CSV to JSON converter. So again, I've got that off GitHub and I've loaded that into that file share and it runs in that container, basically, to be able to do that. And that allows me to parse the CSV file, pass it across to this converter, and then convert it into JSON so that the SCIM input can understand it. So where am I getting the file share from? I've got my demo CSV etc as well. I'm getting the records off that CSV file. I've converted them to JSON. I'm parsing it, putting it into a ray etc. All of that is done via GitHub. The most important thing is actually constructing the SIMD user, and then the loop that goes in for each SIMD user. So what this is effectively doing is taking the attribute that I defined in my CSV file and then converting that into a SCIM attribute. So then when I go back to my mappings, these refer to my SCIM attributes. You know, so let's take this drive C that comes in for countryCode. I've then got what attribute that actually relates to in Azure AD. So it comes in via SCIM and then writes into Azure AD or writes directly to on-premise. And then with that, it's then going to loop around that, create the users, and then call upon my SCIM endpoint, so that individual upload point I called earlier on, to allow that unique one, to then create the user and get them provisioned, and away they go. So just to say, this is my on-premise domain controller. So as you can see, all I've got is one user in here so far. Just a proof of the point, just for demo purposes. So it's just hitting F5. You see the little flick of a refresh up. There's nothing in that.

So if I go back to my API endpoint here and I run this, and fingers crossed it's going to be able to talk to the web server and all the rest as well (technical issues 35.51-36.18) And again, this is something I've just thrown together. You can grow something far more stable. This is me figuring it out along the way and basically getting it going (technical issues 36.25-37.32). It's just a bit of configuration at the back end. But that would have created my users on-prem, which I could then synchronise into the cloud via AAD Connect. I just need to play around with the logic app to actually get that going. What I can do elsewhere is-, I created one as well, a file that I can provision directly into Azure AD if I wanted to as well. So I can run this one. Fingers crossed that one is going to run as well. This one might fail as well for the same reasons. But yes, I can basically get the app to provision directly into the cloud as well. Are there any questions from people? I appreciate that has been quite a lot of information. But that is what we can do for the joiners, movers, leavers process and normally it works, as I say.

Aaron: Nothing much in the chat either.

Chris Howett: I've stunned everyone into silence. Is there any feedback at all? (silence 38.50-39.01).

Aaron: I think, at least-, you know, so I look after London Authority and a lot of the requests are are getting are to help with this, to automate this process. Because it is a difficult thing to do and it is obviously quite manual. So whatever can be automated is a key point in optimising the actual workflow and the lifecycle and whatnot. So the conversation is ramping up quite quickly, alongside London customers at least, across local authority. There is a hand up.

Chris Howett: Yes. Eduardo, I can see your hand is up.

Eduardo: Hello, Chris. Yes. Thanks for the presentation. It was good. My questions are around the provisioning of users. So you've mentioned towards the lifecycle workflow there would be a user without any permission, just a blank account where then you would assign, say, a temporary password and user configuration. And there is mention of user communications as well. Will that account then have a mailbox assigned to it at that point (TC 00:40:00)?

Chris Howett: Yes, because you can associate it to a group. You'll then use group-based licensing to create the mailbox. So once they've been assigned a licence, the mailbox will then be provisioned.

Eduardo: So that would be part of the workflow that falls under the user configuration, or would that happen prior to the entitlement management steps?

Chris Howett: So it depends on where you want that to sit in the workflow. But ultimately, for that to exist, the user needs to be licensed. So the account would need to be provisioned. A licence would need to be associated to that account so it can then provision the mailbox etc for that account. And as I said, it depends on when you want these to trigger. Most importantly, as I said-, so if I go to do a joiner's process for whatever I want, currently what we've got is the employee hire date, and that is the primary trigger that we've got. We are adding more triggers in, but right now, it's just on the employee hire date and what we're going to read from that. We then scope that of who we want it to, so we can pick out attributes that we've got from that user as well. So we can say, 'Yes, we've got employees that are starting in the next 7 days that are going to be in the marketing department,' as this one has automatically put in there. But whatever attribute you've written in from the site. So this is what lifecycle is going to affect which users. This is how we are effectively scoping the workflow. So this one is going to affect everybody in marketing. So what I can then do is create a bunch of tasks, what I can do on that side. So I can enable the user account, disable it. I mean, I'm not going to re-do all these off there. But I can have, 'Okay, well, 7 days before they join or 8 days before they join, I want to provision the account and I want to add them to a group.' So I've got an option there, 'Add user to groups.' And I can add them to a group, and adding them to that group then does the group-based licensing. And at that point, they are then provisioned a mailbox and all the rest as well.

Eduardo: And then they send a welcome email.

Chris Howett: Yes. Give that a chance to provision, sync up, all the rest as well, and then 7 days before, I send the email etc as well. Or the day before, I'll send the welcome email to them, but 7 days before, I'll do a bunch of stuff to communicate with their manager. You know, to say, 'This user is coming online.' However you want to do that. I mean, that is what I would do personally. Whatever is part of your workflow.

Eduardo: And in terms of temporary password, that can be set as one of the rules later on in the workflow where an email, for instance, gets sent to the manager.

Chris Howett: Yes. So 'Generate TAP' and send them an email. And with that, the TAP is a temporary access password, so we can then say, 'Generate the TAP and send them that email,' so the manager then actually talks to them on the day, hopefully. Or maybe you can send the email to a 3rd-party account or to their personal account. I wouldn't necessarily recommend that, but it's still an option. And that might be relevant for, as I said, more front-line workers. As I said, like, the lollipop people or the dinner people, the people who typically wouldn't necessarily have an account. So we can say, 'Yes, we'll send that to them personally.' The information workers and those who have got access to damaging things, i.e. everything else, you know, you would do it via their manager. However you want to get it going.

Eduardo: And MFA enrolment and the SFPR enrolment? Is that then left to the user to follow the steps through, or is that enforced based on the policies?

Chris Howett: Yes. So they will go to aka.ms/setupmfa and they can sign in with the temporary access password. And the temporary access password, as I said, is seen as an MFA sign-in, because it's so short-lived. There's less chance of it being phished or anything along those kind of lines. It's designed for limited use, basically. So you would have that as part of the temporary access password. The user can potentially sign in multiple times with that temporary access password, not just as a one-time thing-, sign in, and they can then use that to set up MFA and enrol into self-service password reset. And then they can use that process to separate their own passwords. But most importantly, they've enrolled into all that security configuration on day one, so that they've got the security on day one.

Eduardo: So they rely on the user having-, or, say, it being done through a handover or having someone else there with them. It's actually enforced at the time of signing up the first time.

Chris Howett: Yes. So I mean, I need to take a look into it, but as I said, we've got these custom tasks and these custom tasks can be a logic app as well. But as part of the welcome emails, you might attach some guides, 'This is how you set up MFA,' and things along those kind of lines. But most likely, they're not going to see that until they've actually created their temporary access password. So just make sure you've got a proper process to actually hand over information. Any guides, or anything you think is going to be a little more difficult, or where somebody can't talk them through it, or whatever else as well, you just need to have something, 'Go to this website,' or whatever else as well and, you know, 'Here are our guides and how to on-board,' or whatever else as well.

Eduardo: That's perfect. And the only other question I've got-, at the beginning there was mention of DAPR being able to connect to both on-prime and Azure environments. Is there any other limitation that you're aware of, or has this been tested in hybrid environments?

Chris Howett: Well, normally it would work. So mine was a hybrid environment. There's a problem, probably with my logic app. So, it's got a bad request. So what I probably need to do to solve this problem, on the fly fixing, just to see where I've got the problem here. I might just need to restart my provisioning, as simple as that. So if I go to 'Provisioning,' and just restart the provisioning service, stop and start it again, there may be something stuck in memory or where I've, politely, been playing around it, for lack of a more diplomatic term. It's probably just broken some of the provisioning, or there is something stuck in there. So if I stop and start that again-, I probably could have done the restart as well, and then try firing that logic app again-, so if I go back to my bulk upload here and trigger, fingers crossed, it will work this time. Ah, no. It's still bottoming out. I need to look into it. But hopefully you can see from previous ones where I've been playing around with it, it was working really nicely.

Eduardo: And on the last steps, the users being removed, is that granular as well, as in, in terms of what you remove and retention of remaining data, say, for mailbox and other?

Chris Howett: Yes. And this is one of the things that we're talking about internally, and we're actually going out to communities like the LGA. We've got something called the Innovation Collaboration Forum where we can do these wrappers to go around it. So it could be-, So as part of the lifecycle workflow that goes with this, if I go into identity governance and the lifecycle workflows-, it could be, as you created the user, that that then triggers events-based retention, or something like that as well. Now, there would have to be other work that's done to go around that to make sure that there is relevant meta-data and all the rest in the documents to trigger that retention. But that should be managed via Azure, via Purview anyway. But yes, you can do something that can fire a trigger to fire off events-based retention.

Eduardo: Okay. That sounds good. And in terms of attestation, you mentioned at the beginning where you would, kind of, review the access over a period of time, say if the user was to move to a different department, or something along those lines. Is there anything that can be done in terms of automation to be put in place which, kind of, carries out that review on our behalf?

Chris Howett: The review is optional. So you don't have to give a review. So therefore, there is nothing for somebody there. The idea of the attestational review is to have that accountability, and somebody has actually agreed to it or whatever else as well. It's not just an automated process that's just blanket done something. You know, 'Oh, crap, I didn't want that to happen, because that user still needs access to these resources,' or whatever else as well. So that's up to you on that workflow, whether or not you do the attestation or not.

Eduardo: So it will be still, sort of, a manual process. So if, say, Entra notices that the user has now been given access to resources in a different department, will it flag up anywhere that those other resources might no longer be required, or will it still be a manual process?

Chris Howett: Yes. So there will be an access review for those processes. So you could either do it to say, 'Well, the access to those resources might just be group-based.' So simply adding and removing somebody from that group automatically adds them in, no attestation or anything required. It's all done on the fly. The attestation, as I said, is more empires and kingdoms. So rather than trying to manage the entire empire automatically-, and that's never going to work, because 90% of the users probably don't fit into that category, or they wear just that one cap and only do x, y, z. So the idea of that attestation and the autonomy is to say, 'Okay, well, the bits where somebody may be on-boarded automatically as finance, but they also have HR responsibilities as well,' finance will be automatically done, but they might have to go off to HR to say, 'Yes, we request access to this data,' or whatever else as well. Or there might be separate workflows, just, like, this one reads this attribute to say 'Finance,' and you might have an additional attribute to say, 'Extra responsibilities.' And you say, 'That contains HR,' or pick your business area. It can read from that and do some automation around that side.

Eduardo: So it can highlight, say, discrepancies. Say, a user was to move department further down the line and they were to retain the old permissions. So the system can highlight that discrepancy in some form or another to say, 'Do you still need those older permissions?'

Chris Howett: Yes. So the main thing is that individual-, that's where you need that user accountability. So example, and the one I always (TC 00:50:00) call out in my customer meetings, is to say, 'Okay, well, user moves from finance into HR.' So let's say they started 3 years ago, now moving from finance into HR. So your automated process kicks in and kicks them out of finance and adds them to HR and the help desk then gets a call going, 'No, no, I still need access to the finance resources, because I'm doing a handover. So I'm not permanently going to be wearing that cap, but I might only have it for another month,' or whatever else as well, while that handover actually happens. And that is the bit where generally, permissions then explode, because you've added somebody to the group, but there is nothing to say, 'Take them back out.' And that's where that manual approval, that autonomy, is actually required to say, 'Yes, Bob. He's still finishing the finance handover. He needs it for another month,' or whatever else as well, or another week. Or yes, 'The finance is done. Bob no longer needs access to finance resources.' And we can reclaim, potentially, licences and things like that as well for finance applications.

Eduardo: So can a workflow be implemented, then, to automatically remove those permissions in a month's time? So whether it's file shares, group memberships or mailboxes, whatever the case might be.

Chris Howett: So what you would have in the access review-, it depends if people respond to it or not, basically. And what you would have is recommendations within the access review. So that would say, 'Well, this person hasn't accessed the resources for X amount of time.' So at that point, we can automatically remove it. Now, if somebody is manually doing that, they'll see a big recommendation saying, 'Bob hasn't accessed these resources. Kick him out.' Or you can say, 'Bob, do you still need access?' And they can do that attestation. Or you can say, if whoever is doing the review doesn't sit in with that, doesn't have that side of it, or doesn't respond to the review, 'Actually, then, respond to the recommendations automatically.'

Eduardo: Okay. Yes. That's good. But you can add the element that will not fire you, or you can set the threshold of how long before you actually notify.

Chris Howett: Yes. What the threshold is before somebody responds, or you can say, 'If they don't respond in this time,' there could be that catch-all person. You know, somebody to say, 'Okay, yes, do we want to have just you on that?' That might be somebody on the help desk or whatever else as well, to go, 'Nobody has responded to this access review,' or whatever else as well. 'How do you want to deal with it?' So you can have, again, some accountability, or just ignore that step entirely and just kick them out.

Eduardo: That sounds good. If there are going to be any future sessions, it would be good to see that component, that part of it, as well.

Chris Howett: Yes. I need to get all that built together. As you see, it's quite complex. I need to build a very large environment to show you that end-to-end. Working on it, getting there so I can show that.

Eduardo: Yes. I expect that's got to be the one that affects most, if you like, authorities or environments where people move departments and they might retain the previous department's permissions, and so it would be good to see that in action, see what the system can do for us in terms of automation.

Chris Howett: So ultimately, what we would have is these mover processes. So if I select a mover process, what I have, as it currently stands, is just some tasks that we can do as part of that mover process. These are forever growing, and there will be more and more added in, but most importantly, we've got that custom task, and we're loath to throw everything out to logic apps, but logic apps allow you to do anything. So yes, there is an absolutely tiny cost to the logic app as well, and I think you have to run, like, 3 and a half thousand of them to be able to rack up a pound cost in Azure. So depending on how complex, and obviously what the logic app is doing. But they are typically very, very cheap, to be able to fire those off. But yes, so that then allows you to do whatever it is you want to do via a logic app, basically. So that then says, 'Yes, we want to fire something back off on-prem,' or we could trigger something else. And then, as I said, we're working with other teams and partners at the moment to create a bunch of wrap-around processes using Azure integration services. So it can integrate, and you can do all of this, and you can tweak it to your heart's content.

Eduardo: Sounds good. Yes. There is plenty of time to learn it all, I think.

Chris Howett: Yes. But the point we've got here, I appreciate, is additional licensing. Ultimately, (inaudible 54.07) the connectors to go on-prem to be able to talk to applications, we can manage the whole of this from the cloud. We can then have, sitting there, very limited interfaces. Pretty much manage the whole lot through the Entra admin centre. You might have something in Azure if you've got any logic apps, but hopefully, they're automated. I've kept it as manual just for demo purposes, basically. But you can see it all works. It just flies together and it's all automated. And so we then have the integration services. That then allows you, especially for the movers processes, to integrate and to have a thing. So it could be, well, actually, there does need to be some human intervention to perhaps reconfigure a device or something like that as well. It can't be done automatically. Or they might need something physically new. So it might be to say, 'Well, yes.' That kicks off into, I don't know, Servicenow or whatever your ITSM fill is, Hornbill, or whatever it is, to then say, 'Right, could somebody go and create this for this user?' Yes? Or go and figure this out or do something physical for this user, you know, as part of the movers process. Okay?

Eduardo: Yes. Sounds good. Thanks.

Chris Howett: So it also says, 'Can you cope with user multi-role situation?' So that was one from Jenny there. It would be really handy to know what you mean by that as well.

Jenny: Yes. Just, like, very often a user works part-time in one department, part-time in the other department and doesn't necessarily move. So in this case, what could the workflow handle?

Chris Howett: Yes. So this is why I talk about empires and kingdoms. So the kingdom is the business area where they're working part-time in one and another kingdom is where they work part-time in another. I'm just using that as terminology. I don't mean to confuse. So that's the business area, or whatever else they have got. So what the user can do is go to myaccess.microsoft.com. And from here, they can now request access to packages or access to other kingdoms or whatever else as well, whatever is being presented to them. And that will have been sent out as entitlement management. And this is E5. This isn't part of the lifecycle workflows or anything like that as well. So I can now request access to these additional packages. I'm very limited in this demo environment that I have created here, but I can go go this and say, 'Well, yes, I've been automatically provisioned into business area 1, but I can come here and get access to business area 2.' And this is why I say you can never fully automate the joiners, movers, leavers process, because you don't know what different business areas people are going to be working in and how they grow and move through the organisation as the organisation changes over time, which is why you have that autonomy. So we've automated the first part and we now give the autonomy for the second part, so we can compensate. So the user can self-serve entirely, and we have all those approvals and all the rest as well. It just requires some bit from the user to come in here and go, 'Yes, I need access to this as well.' And they go to myaccess.microsoft.com and they can pull up whatever they need. So they can sit in 18 different kingdoms, using that terminology, and they just have to request access to the other 17 there that they want to be put in. Does that make sense?

Jenny: Yes. Thank you.

Chris Howett: Yes. This is why I say, like, 90% of your users are not going to fit into the automation piece, just because that's just the nature of public sector. I've worked there myself. You know, you end up-, as soon as you've got skills in something, you've ended up wearing that cap as well and your role kind of expands over time. So some people genuinely need access to all these kind of resources, but more often than not, people have just moved and IT either isn't told or there is some other loop or whatever. Like I said, that handover process, when people just maintain permission. So this is a way of saying, 'Well, actually, we've got that attestation, and we fire off that attestation as often as you want it to happen.' And so the option for weekly, monthly, quarterly, half-yearly or yearly. So that depends on what level of churn you have and how quickly you want to have it. So it could be as part of the, you know, examples of what else you could do with these kind of access packages and entitlement management-, so you can say, 'Well, we block access outside of the UK,' because that's just good security and, you know, typically you don't need to access-, well, the UK public sector doesn't need to access beyond UK borders. But you then have an exception group, and that exception group allows people who want to go on holiday and, strangely, want to work while they are on holiday-, you say, 'Great. We add them to the exception group.' And then every week, there might be somebody in IT going, 'Why are you still in the exception group?' Or, 'You said you'd be back from Azerbaijan or wherever else as well last week. Great. We're still accessing from Azerbaijan. There is something wrong here.' You know, we can flag that, so we're going to take you out of that group, you know, so your account can no longer authenticate from outside the UK. Okay? Picking a random country there, starting with 'A.' Does that make sense? So lots of autonomies. Lots of controls we can put in there. Lots of automation. And we can tweak this to your heart's content. And just as a final bit to add, we are working with, like, the innovation forums, and we're working with partners and things like that as well, to create some standardised wrap-around processes. Final bits I'm going to show you, just to feed this back. I'll share the slide deck with you today, but what I'm doing with the slide deck, once we've actually got that built out, is, each area of this is actually a Zoom. So you can then go into there. So I close that one off. The one I'm working on, I need to pretty it up and put something on SharePoint. This is how SharePoint would actually integrate into the joiners, movers, leavers process. You know, on that side, this is how Teams would do that as well, SaaS app etc. I'm working on it. I need to pretty it up. I've only done those 3 so far. But you'll be able to have all of this information, all the links, so you can understand this from end to end, basically. So I will share (TC 01:00:00) this in its current format, but as and when I've got this fully completed, I'll share it out again. Okay? And with that, I'll hand back to Aaron and any other questions.

Aaron: Brilliant. Thank you, Chris. Yes. Any more questions from anyone else?

Chris Howett: Most importantly, has this been helpful for people? Is this relevant and helpful? Are we on the right page yet? Cool. Yes. David?

Ellie Stewart: I am going to share a feedback form in the chat now so that there is opportunity to feed back on the session today and also a chance to put in there any other emerging topics that you'd like Microsoft to cover or the LGA team as well. So I'll just put that in there now.

Aaron: Awesome.

Ellie Stewart: Brilliant. Well, if there are no further questions, I just wanted to say thank you so much to the Microsoft team. The next event we've got coming up is on generative AI and fuse SecOps and security co-pilot. 26th of October, 2 to 3 p.m. So I can share the link as well, with the feedback response that will be coming round to you after the event. Thank you so much.