Episode 5: Interview with Jono Luk, Senior Program Manager

This week we finally deliver on our promise and give you an interview with someone no less than Jono Luk – the man who “owns” DirSync for Office 365.

Well, it’s really a bit more complex than that so tune in to listen to Jono and the team talk about the history of DirSync, recent changes, and upcoming features.

There’s also a bit of Office 365 news in there – get listening!

Check out this episode | Download this episode | Subscribe to this podcast

Transcript of Episode:

Welcome to another episode of Office 365 FM. Yep, we’ve got them coming thick and fast. This week we’ve got one of the interview, thingy-ma-bobs we’ve been promising for weeks. Yep, it’s real and it’s spectacular. This episode your host is Sean McNeil with panel of experts, Jethro Seghers, Loryan Strant, and Martina Grom. Today, we interview Jono Luk, senior program manager at Microsoft for Active Directory. Let’s get into it, shall we.

Sean:                I would like to welcome everybody to episode five of office365fm.com’s Office 365 podcast series. Today, we’ll be interviewing with Jono Luk, a senior program manager in Active Directory including Windows Azure Active Directory. We’ll be talking to him about what’s new in identity management and DirSync and we also have just a couple quick little tidbits of new information that came to light since our last episode. But first off, I’d like to introduce my distinguished panel of guests including Jethro Seghers, Loryan Strant, Martina Grom  and I’m your faithful host Sean McNeil.

Given we only released a podcast a week ago, there hasn’t been much happening to update you about. Oh, except one small thing…

Sean:  To begin with, I’d just like to touch base real quickly. We’re recording this podcast, it’s Monday January 27th, and when I got into the office today I got hit with a few emails and tweets about Microsoft has come up with a new name for SkyDrive, so now you will be, on the consumer side. You will now have OneDrive, will replace the name SkyDrive and not to be outdone, for SkyDrive Pro whether it be on-premise, in SharePoint, or in SharePoint Online, that will now become OneDrive for business. So still staying with the base name there of OneDrive for both, but now with a little more emphasis, instead of OneDrive Pro, I do like that they are at least using OneDrive for business.

Announcer:  Wow, that was fast! You’d think our crew were running out of things to talk about. Nah, if you’ve seen them present Live, you know they’ve got a lot more to talk about. Let’s get into the interview with Jono Luk. Take it away Sean.

Sean:  Where I’d like to transition to right now is to introduce and welcome Jono Luk. Jono, thank you so much for taking the time out of your busy schedule to sit in with here at Office 365 FM, and talk about identity management.

Jono:  Yeah, you’re more than welcome.

Sean:  Well, as I mentioned, Jono is a senior program manager with the Active Directory team at Microsoft, which also does include Windows Azure Active Directory, which as those of us in the know and using Office 365 now for any length of time really realize that Windows Azure Active Directory is the directory services that are- Office 365 relies on. So Jono to start off with, I’d wonder if you could just give us a recap. There’s been several, you know, really big announcements, changes, and enhancements to directory sync and identity management as a whole. So if you could just go over some of those key highlights.

Jono: [Inaudible 00:03:28] six month, we released a password hash sync feature for DirSync. I do believe it was about it was about June last year, around when Tech Edge would help, that gives customers of Office 365 and Azure Active Directory an opportunity to synchronize passwords from their on-premise active directory as an option or alternative to setting up single sign on with ADFS or other such IDPs. We also released support for deploying DirSync on domain controllers, this has actually been one of our bigger apps, you can imagine for a variety of reasons.

From, “Hey, I just want to give this Office 365 thing a go. Let me just set something up real quick, real easy, and deploy that.” And for the longest time we didn’t support that. There is a couple thing under the hood that we had to go and rewire, but we really think it’s going to be some goodness for all of our customers by being able to deploy DirSync on domain controllers. One of the other items that we put out there, I believe this is around November of 2013, we released the Azure Active Directory connector for FIM 2010. So for those of you that are already using the product, you’re probably aware that the DirSync tool, or Directory Sync tool as we formally call it, is built for a single active directory force. So for customers that had more than one AD force, of which there are many customers that’s like that, you didn’t really have a DirSync equivalent. The Azure Active Directory Connector for FIM is that solution.

It’s a little bit more do it yourself, you have to [Inaudible  00:04:58] deploy the sync engine [Inaudible 00:05:00], deploy the connector. But now any customer with any number of active directories on-premises can synchronize that data up into Office 365 and Azure AD.[Inaudible 00:05:11] I think that covers the three bigger things we introduced, at least in the last six months in the Sync Space.

Sean: You know the first two you mentioned I think, are extremely helpful for the smaller end customers. You bring up a very good point is, with not being able to install DirSync on a DC, I had to have another server on-premise to handle that and then when we did the ADFS, at a minimum to make sure that’s highly available, you needed four additional servers. Now, with the ability of not needing to deploy any additional servers beyond my existing domain controllers to be able to implement password synchronization, I think we’ll talk a little bit more about this as this episode goes along.

With that same sign-on feature, the ability to use those same credentials on-premise and in the cloud, as well as, now installing that on that DC, no net new servers need to be installed. The realization now, when an Office 365 deployment, whether they have on-premise exchange servers, I can now actually say that we will be removing servers, and not ultimately adding servers because I’ve had many cases where a small company, maybe 500 users had two exchange servers, while I would able to remove those two, but because of the four ADFS servers and the DirSync servers, it was a net add of three servers to their environment. So, great news, and thank you8 very much for the recap.

Jono: I think you hit it square on. Our job here is to make it as easy, as simple as possible for customers to get to the cloud, so anything we can do to help is squarely in our purview.

Sean:  I’ll open up to the panelists. Your thoughts real quickly, on that ladies and gentlemen.

Loryan: The easier the better, the faster the better.

Jethro: How easier it is to set up the more, also like confidence, users will have into a system and it will increase only the adoption.

Sean:  I would now like to turn this over to the more interview section of the podcast, and hopefully, Jono’s not getting too squirmy in his chair, that I’m going to open it up to our panelist of experts here to ask questions about the future, and what’s coming down the road from Microsoft around DirSync, Active Directory, Windows Azure Active Directory, and Federation as a whole. So, with that I’m going to turn over the first question is going to be from Loryan. Go ahead Loryan, ask your question.

Loryan: Thank you Mr. Sean. Just testing this, okay, so my question is [Inaudible 00:07:50] there’s such a formal hand over Sean, I just had to make it like I was sticking up to the mic. So, Jono for so long with Office 365, we’ve had the guidance of ADFS, and we even had the, I think it was the Office 365 connector was the white paper released about how to efficiently build out ADFS infrastructure with DirSync, the main controller, ADFS servers, those kind of things, whereas now, with Password Sync, we’re seeing a completely different scenario.

So, we’ve got customers who are only a couple of hundred of users in size who have ADFS in place. We’ve also got a customer 10,000 in size who just has DirSync with Password Sync, actually sorry, we’ve also got 50,000. So, I guess, why should organizations choose DirSync with Password Sync over ADFS or vice versa, like any tidbits of guidance as to how they should be making those choices?

Jono: Yeah absolutely, so that’s a good question. The one thing I want to start with and Sean used this term, I like this term a lot. Password Sync gives you same sign-on, so from a user’s perspective, when I’m logging into my mailbox Password Sync lets me used the same password when I’m logging into Windows as when I’m going to access my mailbox by [Inaudible 00:09:09] or something else.

Single sign-on takes it on takes it one step further, and there are scenarios when I don’t need to type that password again but from an end-users perspective, that’s the first difference, that the most the important thing to call out here, because if all that you really want is to minimize the pain and the sticky notes which we all know exists. The sticky notes under the keyboard and in drawers, if you try to minimize that and make it as simple as possible for your users to just sign with the same password, then same sign-on or Password Sync is good enough. But that being said, there is absolutely categories of security and enterprise requirements where you need more than that. You need for example multi-factor authentication or in some case, you need to go so far as to implement solutions where credentials don’t need your on-premises directory, for whatever business segment you might be in, that might be a requirement. That’s where single sign-on with ADFS is still what’s going to solve your problem.

Password Sync, and as you called it Loryan, there we have customers of up to a million users using Password Sync. So, it’s not a scale question, it’s not a question of how big is the customer. It’s really about, “What do you need to accomplish?” If it’s about not having to have your users know two passwords and remember two passwords, have their expire at different times, that’s enough, for a lot of customers that’s good enough, then DirSync with Password Sync is what you want.

Like I said, the multi-factor authentication scenarios or custom authentication solutions, smart card based [Inaudible 00:10:50] for example. Those are squarely in the realm of single sign on with AFDS at that point. I hope that answered the question for you.


Loryan: Absolutely, I think that a lot of people don’t even think about the additional solutions like multi-factor auth. When they look at them they just look at the server count and [Inaudible 00:11:08] so I think that’s really helped put a perspective, thanks Jono.

Jethro: Hey Jono, thanks for the answer on the previous question as well, and it actually leads me to my question is that certain people actually implemented ADFS to have that same passwords or SSO, or they chose to go for ADFS. With release of DirSync with Password Sync, we had a lot of people going back. You mentioned the different things why ADFS is also sometimes preferred over DirSync or Password Synchronization, but what about a combination of the two? For ADFS, we need high availability, but can’t you use DirSync with Password Synchronization somewhat as a back-up for ADFS?

Jono: Yeah, actually that’s something we’ve been asked for quite a lot since we released the Password Sync feature, and it’s something we’re working on actually. I think it makes total sense. There’s goodness in ADFS, there’s features like we mentioned here, sort of custom authentication flows, smart card based login, all those thing that only ADFS can give you and maybe it’s the case that you don’t have a secondary site so you can’t build up a DR solution. So we’re working on support right now, we’re revisiting our staff [Inaudible 00:12:23] so that we can offer this in the long-run. We’re trying to figure out exactly how that’ll work, what the processes are but you can imagine some point in the future you’ll be able to use Password Sync as a back-up for ADFS so you can deploy that primary site, get the goodness of ADFS. If something goes wrong with that infrastructure, any number of things obviously can happen, you could switch over and now fall back to synced passwords that is from Federated state. But absolutely, loud and clear apps for customers, it’s something we’re evaluating right now.

Jethro:  Yeah, that’s a feature that I’m very looking forward to that, so thank you for your answer.

Martina: Jono, if you manage users on-premise, and you don’t have an exchange server left in your active directory, it’s sometimes really hard for people to manage their users. So, would there be an extension of DirSync which helps us manage email addresses also with DirSync for example, global address list hiding, distribution list management, and stuff like that?

Jono: Yeah, so that’s a question, actually we get a lot as well alright. What we’re looking to do here in the next while, and we’re working actually very closely, we’re the directory team, the team I’m on, we’re working very closely with all the services. The same question could be extended to SharePoint Online. Why can’t I use the SharePoint Online Mysites? For people that manage their thumbnail photos, it’s a very common pattern. We’ve gotten  asked that a lot, and we’re evaluating how we can support this so we can do exactly what you suggested.

I have an AD on-premises, I’ve spent fifteen years modulating and managing that. Now, I came to your cloud, and I want to use certain features in your cloud for my user management. So, we’re looking at what scenarios there are. What are sort of the most prevalent scenarios that our customers want, and then trying to figure out how we can support that because, this kind of goes back…

I think, that Loryan or Sean had mentioned, if you’ve migrated to Exchange Online you don’t want to have to keep anymore exchange on-premises footprint, you want to get rid of that. So it’s a very [Inaudible 00:14:38] app, it’s something we’re looking at, at how we can sort of facilitate this. I always kind of term it, user management from the cloud, meaning things like email addresses or your thumbnail photo, your phone numbers is another example. So, absolutely, something we have here that we’re evaluating on our road map.

Martina: And for example, would it be possible sometimes that we have kind of a two-way sync? For example, users change their pictures in SharePoint Online and that picture’s got into the local active directory for instance?

Jono: I should have seen that question coming given that answer I just gave to the last one. Yeah, we are working on exactly that. Earlier, I was sort of referring to user management in the cloud. What we’re trying to figure out now is exactly like you said, two way sync, and allow data to flow in both directions. I think that the way that we want to build this is, you wouldn’t think of it as, “I’m going to go to this directory and touch this object and this attribute.” It’s more, “I’m using this feature of Exchange Online, I’m using this feature of SharePoint Online.

I make a change on a DirSync user, and that change now shows up on-premises or, I’m using this feature of Office 365 which creates a group, a new DL in the cloud, and then allows it to flow back into the on-premise [Inaudible  00:16:02], so those kinds of two-directional sync things are a part of the bigger picture that I’m trying to work on right now. How can we build these so that you and the administrator, or even the users, it’s really sort of transparent where you are making your changes.

You make a change somewhere, it ends up everywhere. These are the kind of conversations we’re  having right now to understand better what exactly we can do, and in what time frame but, it’s absolutely in our road map, because tons of customers are asking for that.

Martina: Oh good to hear that, thank you.

Loryan: So, Jono, some of the feedback we’ve seen with regards to the password synchronization was that that the hashes can be hacked and I guess, realistically, anything can be hacked if you go to that extent. What are your thoughts on, and what concerns has Microsoft seen in what content is created around ensuring that people feel safe when they’re password is synchronized from Active Directory to Office 365?

Jono: That’s a great question, so let me actually take one step back and just sort of baseline and say, when we say Password Sync, this new feature that we spoke that’s in DirSync, exactly as you mentioned Loryan, is password hash sync, to just baseline there. So, in terms of security, that’s our first foot forward in making it better. Most, if not all existing password sync solutions out there in the marketplace either are transporting plain text passwords, or encrypted passwords, using reversal encryption. We built our service in this feature so that we take it one step further and actually work off the password hash. As you mentioned it, it is possible, it is mathematically possible that hashes can be reversed, but very, very unlikely.

So, from a security point of view, and we worked with a security architect in Windows Server in Active Directory and the work that we’ve done there, we actually re-hashed the hash to be totally clear, so it’s double hashed. That’s what’s actually transported from the on-premises directory sync machine up into Azure Active Directory and Office 365. We’ve built in a lot of safeguards, so in terms of at rest, we’ve heard a lot over the last year and a half- this service got hacked, that service got hacked.

We have safeguards inside our service that allow us to quickly and efficiently rehash again any secret that we have in our credential store. So, at rest, it’s already a hash of a hash, so it’s two rounds of near mathematically impossible processes to reverse and we also by design, are able to very quickly hash yet again that with an even more secure algorithm. We’re constantly in touch, you can imagine obviously [Inaudible  00:18:55] we guarantee our Office 365 customers have the most security.

We’re always in touch with the latest and greatest authorities on what’s appropriate, what algorithm levels are required, and anything that’s been compromised, so that’s our overall strategy. We believe that there’s definitely good, we have faith in that.

Loryan: [Inaudible 00:19:15] a lot of people. Thanks Jono.

Jono: Actually, one other thing I just want to throw in there is in terms of the hash, we store, like I said, a hash of a hash in the cloud. Even if you’re able to revert that hash, hashes can’t be used to gain access to your on-premises resources. So, I can’t come in and say, “I have John Smith’s password hash, let me in.” The fact that we have multiple layers of hashing already, sort of, makes it literally safer and even if you were able to reverse the first level of hash, you can’t just bring that, you have to two full iterations of the unhashing in order to get to that password, which again, is near mathematically impossible.

Loryan: Wow, really good to know. Thank you for that [Inaudible 00:20:00], as I said, that will really put a lot of people, I think, at ease. That is really going to put a lot of  people at ease to know they can’t use the hash and its total hash so that’s fantastic, thanks Jono.


Jethro: Hi Jono you referred in the previous question about the safeness actually of the Password sync by using double hashes but what about stupid user passwords?  So, for example, I can limit the password policy on my AD to a single character password policy.  How about synchronizing that to Office 365 is that non-reduction actually of the security of multi- [Inaudible 00:20:32] system?

Jono: So that’s a great question, I think there’s a couple of different pieces in there.  So, the first thing was, is you now, what happens to password policy once you’re password synching, right?  And what we do is, we literally defer to your on-premises AD password policies.  The reason why, from a technical standpoint is, we synch the hash of the password but by the time we see it, it’s already hashed.  As I promised earlier, it’s almost impossible to reverse the hash right so, we can’t look at the actual synch password to know the password are password Policies in the Cloud.

That’s when we let it through.  Now, you mentioned and it’s a very fair question, what if the admin says one character is allowed, right, any character and no password history or anything like that and passwords never expires. Well, we would consider the loop password policy requirement for your on-premises AD.  You’re absolutely right, because of the design we have, that password would make its way up into the Cloud.  So, the thing here, I kind of want to split the conversation into two parts to answer your questions.

The first one you had was, or maybe it was the second part but the question was, aren’t we sort of making or potentially compromising our service by allowing that to happen?  Well, first and foremost I want to make something really clear. The way that our service or directory is built, one customer can’t overlap with another customer. It cannot access another customer’s data in any way shape or form.  So, if you think of it, in terms of a mounted cloud in the sky, they’re basically partitioned or segmented, so it’s Contoso password policy with one character, no history and  Fabricam with 27 characters with two capitals and a special.

You know, in the context of security diagram the Contoso users can’t get at the Fibracam’s user data. So with that division in mind, now we’re kind of looking within the Contoso picture right, just within the Contoso data set, the directory data, exchange and all that.  You’re right, what we’ve done is we allowed the silly policy on premises to carry out it to the Cloud.  We said it was okay for you to have a single character and now you can bring it to the Cloud as well.

So reason why we went down this path we tested the waters  with actually quite a few customers. This is the same thing if you were actually setting up ADFS, using single sign-on.  In the case of single sign-on, the only difference is the on-premise STF ADFF  is what’s finding your users but the password is the string they enter has the same complexity and so, in, what we sort of landed on would, it was okay for enterprise because we are very safety conscious because again, you control this password policy.

The customer that want very complex, very tight grade password policy do so and in those customers that previously  deployed ATFS but only have a single character, like for the  example that you gave. Then yes, they carry these passwords over but that’s the same thing they would have had had they had a single sign-on just for password synch.  So, hopefully that answers your questions a bit ago or allay some of the fears where one customer’s decision to have poor password policy can’t hurt another customer by design.

Jethro: Okay that’s a fair point.  Just one small follow- up question actually is that, so, at certain points you have your synch password synchronization you have very poor password policy regarding your passwords on-premises, what happens to that password policy when we actually disable DirSynch with Password Synch? So, we’ve synchronized those double hashes through the Clouds for the password and we actually go back to a cloud based account.  What happens to the password policy then?

Jono: Yes, so that’s a great point.  So, what you’re saying is at the time when DirSynch was running with Password Synch, the user was synchronized with the Clouds and the password is synchronized and it is some silly policy like one character. You now turn off DirSynch or for some reason stop any of the above what happens to that password right?  So in this case, the way that the system was designed is, you’ll still get to use that password, the one character password is still there.  However the, assuming it was an intentional transmission to turn off password synch or to turn of DirSynch, the next time the password is set in the Clouds, that new pw would have to match or adhere to the Cloud or Azure Directory password policy.  So, for the window between when the last password was synched and the password is updated manually in the Clouds, there is a potential that that password doesn’t meet our password policy but again, the premise of this is, it was good enough for you on-premise, it was good enough for you to synch that Cloud.  So that window there is really the only time when it has to make it efficient so do I go through this with my user password or what’s the appropriate action to take?

Jethro: Okay, perfect!  Thank you for that very complete answer.

Sean: Love hearing Contoso and Fabricam, just love it.

Jono: With a capital C and capital F too.

Sean: You’ve had some great questions so far. One thing that I’m wondering about is, as new features have been rolling out in DirSynch Directory synchronization, has there been any thought to being able to incorporate those into like a windows update type system so it’s more automatic process than a manual process it is today by downloading the latest bits, installing it on my DirSynch server and such but having it automatically updated just like you would with window OS or any other service?

Jono: Yeah, and again, that is actually a question we get from quite a few customers.  The answer right now is,  it’s not an RDM  road [Inaudible 00:26:17]  but it’s an interesting proposition.  One of the things in the past that we’ve had to overcome, one of the reason why we couldn’t have the design that we do is by default DirSynch moves data from on-premises directory of the Cloud, that’s the entire purpose. It now moves password from your Azure directory to the Clouds.

So, we’ve been very sensitive to the fact that normal customers wants to get the latest and greatest changes right away.  You know, some that, I often chat with folks, where they go to change their keyboard and they want to understand what the changes are, what’s the new data that you’re thinking [Inaudible 00:26:25], what are the new functionality and features that may change how this is being used for you?  So, in those cases, having an explicit sort of if you want the latest, download it and install, that model works great.

Carrying that over now, sort of the general thinking customer base, we do always want to make sure that it is explicit okay by you, you the administrator or by the decision maker, that set of change to happen. So, as you alluded to earlier, you have to download the new [Inaudible 00:27:29] and then you  run it and now there’s an update, we exposed that feature a little bit ago but  it will upgrade the latest and greatest configuration and it’s off to races it is good to go again.  So, we’re looking at sort of introducing company like microsoft.update, which will update the application bit but we still need a good channel to say “Hey administrator, we’re going to do change XY and Z, are you okay with that?”

So, at this point, because we need the admin to do something anyhow to okay those changes, that’s why right now, we’re still kind of moving in this mode of well, then the Jerseys says  because it’s all in one go. It’s absolutely though, something that I’ve had several conversations with customers about and they’re saying, actually I’m okay with it.  I’m okay with it automatically updating.  So, we’re evaluating our options with,  microsoft.update or maybe a better integrated experience with the  admin portal to sort of get that okay, get the go ahead and update please, when appropriate.

So, those are the things we’re looking but it’s definitely a little bit for  the route just because we’re able to currently meet the needs of both customers, especially ones where they do want to be very intentional about making those update at  their application bit or the actual configuration on what kind of data plus.

Sean: To some extent, I never thought about the other side and me being one for I’m always want the latest and greatest so make it easier for me to get it but I guess that’s why you get paid the big bucks to think about the other side that do want to stay back or not be on the latest and greatest and you need to balance that so very good answer and thank you for that.

Martina:           So, Jono, one of the last questions what comes to my mind is I got a lot of questions from our customers, which filtering options are available in DirSynch and which are supported also into DirSynch.  Can you briefly bdescribe what we can do now and maybe what’s possible in the future?

Jono: In terms of what’s supported right now, for the last while, well over a year  and a bit, what we’ve allowed customers to do with the DirSynch Tool, so this DirSynch tool you install it by itself, you can actually go in and modify the filtering criteria and filter users based on OU, based on 80 domain or what I kind of call actual-matching. In other words, all users with the deportment name that starts with students or something like that. So, based on an actual value you can filter out those that are currently supported and it will continue to be supported against the DirSynch Tool.  We do have larger enterprises who want to filter out entire segments of their AD or perhaps use some different form of filtering other than those three mechanism in that case DirSynch by the term if its sufficient for you what we ask customers to do is will use full blown DirSynch in that case, where you have full flexibility to create whatever type of filtering that is appropriate for you, including in some cases, leveraging specific rule, custom rule.

So, that’s kind of how we look at the world and try to help our customers. There’s limited filtering support in DirSynch and those are documented. There’s again, sort of OU based, 80 domain base and attribute value matching for users.  Anything more than that  you don’t want to move to synching because it just gives you more flexibility.  It gives you the ability to clear all those rules and so, that’s really how we currently support it.  We don’t at this time have any additional filtering support plan for DirSynch for the DirSynch engine but if there are any, for sure, I’d love to understand what additional requirements there are because at the end of the day, it’s for our customer needs, that’s why I work here.


Sean: Well, I’d like to thank the panel and Jono specifically for taking your time out day today and answer our questions.  I think you gave a lot of great information. Nice to see that we’ve got some new features coming down, coming down the road and be able to implement those and utilize those in our environment. Again, Jono thank you very much and to the rest of the panel thank you as well and please look forward for the next episode of Office 365 fm.com podcast coming to your computer very soon.

Well that was a different format, interesting.  Stay tuned for more interviews and future podcsast.  If you guys have suggestions on some topics you’d like to hear, submit it via our website, www.office365fm.com.  Until next time.

Posted in Office 365 FM.

Leave a Reply