Preferred Name, Shared UW NetIDs, UWWI, and Exchange

You may be familiar with the friction we’ve experienced over the years around displayName. Here are a couple past posts I’ve written on this:

 

I’m writing to make sure you are aware of a new behavior that was introduced likely at or after the PersonReg 3.0 release (now called IdentityReg). The effect of this new behavior is that the benefits to UWWI of the imagined “preferred name” work for Shared UW NetIDs are, for the most part, here today.

 

Prior to this, if you wanted to change the name value on a UWWI user that was a Shared UW NetID, you called the UW-IT Service Center and asked them to change the AVF displayName value. It wasn’t ideal, but it worked. That still works (except in some cases—more on that in a second), but there’s a better scenario now.

 

From the UW NetID Manage tool, if you set the Name value (see “Basic Settings”) for a Shared UW NetID, it now results in the PDS displayName value being set to that value (overriding any AVF displayName value). This then results in the UWWI FIM system using that value and propagation to UWWI. Keep in mind that account owners or admins can use the Manage tool on their Shared UW NetIDs by logging in with their personal UW NetID, so they don’t even need to have the Shared UW NetID password handy.

 

So in summary, self-service UWWI user name changes have been attained for Shared UW NetIDs. Getting to this milestone for Personal UW NetIDs still remains outstanding.

The 48 Laws of Power

Last year, based on a extremely flattering book recommendation, I read The 48 Laws of Power, by Robert Greene.

Power has a lot of relevance to leadership. I see leadership as the process of influencing others. For example, if you consider the ‘5 steps to making an impact’ graph, there are plenty of examples we can all think of where power is used to skip those steps and make an impact without actually gaining creditability, trust, respect, or inclusion. But the reality is that the outcome isn’t as impactful because the folks following may not believe in where they are led. This is the dilemma of top-down leadership. And to tie in another book I recently read (Thinking in Systems), it’s why feedback loops are incredibly important for leaders whose impact comes from their role, not their progression up the ‘making an impact’ graph (or as power law 18 says: do not build fortresses to protect yourself–isolation is dangerous).

But there are also situations where power is used to help facilitate the steps in the impact graph. And that’s what I’d call a good use of power for a leader. And sometimes, as a leader, you must wield power to skip the steps because there isn’t time for the alternative of progressing up the graph. That’s not ideal, but we don’t live in an ideal world. That’s why repairing relationships is one of those topics all leaders need.

Yes, The 48 Laws of Power talks about Machiavellian ways of getting and using power. Yes, this is very different from the ideas and techniques promoted in the UW-IT Leadership program (or any leadership program). But as Niccolo Machiavelli wrote in The Prince: “Any man who tries to be good all the time is bound to come to ruin among the great number who are not good.” At the very least, you owe it to yourself to be aware of the techniques that might be used against you, and to avoid the worst mistakes of using the power that comes with leadership. “Hence a prince who wants to keep his authority must learn how not to be good, and use that knowledge, or refrain from using it, as necessity requires.” (the rest of the Machiavelli quote above) At the best, you may learn techniques that you can use in a good way as a leader. And be able to share those techniques with your fellow leaders. 🙂

So with that introduction, let me focus more on the book itself.

Each chapter focuses on a single law. All the chapters follow a predictable pattern:

  • The law is presented.
  • Highly interesting historical examples that support the law are shared. These come in two flavors and both are always included, usually multiple examples of each:
    •   Transgressions: Examples of someone breaking the law and losing power (and often their life). Followed by a short interpretation section with analysis.
    • Observances: Examples of someone following the law and gaining power. Followed by a short interpretation section with analysis.
  • Keys to power. Distillation and key points about this law.
  • Image: Words in the form of an image (a word picture of sorts) to help you remember the law is presented.
  • Authority: A quote that states the law in a slightly different way.
  • Reversals: Exceptions to the law are noted.

Then throughout, the margins are used to sprinkle in additional material that reinforces the law. This material comes from fables, historical examples, scripture, and other sources.

Even if I hadn’t been interested in reading about power, the history, stories, and anecdotes included were fabulous. I found myself eager to read this entertaining material and flew through the book. I read about half of it over a period of a couple weeks, recognized I wasn’t absorbing it, set it down for a couple months, and returned to finish it later. I enjoyed the history more than I was learning the power laws themselves. Eventually I realized that I’ll have to re-read the book a 2nd time to really absorb the laws. You may be different, but I’d advise that if you commit to this book recognize that it isn’t just a simple once through read.

I’d especially recommend reading this book if you are a leader who doesn’t have authority that comes from the organization, as it’ll give you lots of techniques you can use. But regardless, if you are serious about being a leader, then this book should be on your reading list.

OpenLDAP Client Loses Connection to Active Directory

Near the start of the year, we had a number of RedHat 6.5 servers apply a set of platform updates. These updates included an OpenSSL update.

We then began to see a number of cross-platform issues when an application on the unix servers interacted with a service hosted on a Windows server over an encrypted channel. On the Windows side, the primary two services involved were Active Directory (LDAPS) and IIS (HTTPS). The error message on the client side was usually “Operations error”. Network packet inspection showed some funny business, including the Windows server closing the LDAP connection without notification to the client.

In some cases, specific to the AD involved issue, some folks have successfully implemented a workaround of changing their TCP port to 3268, following *many* online posts which suggest this as a solution. That workaround has two potential problems:

  • The GC port is a subset of all directory info. So you get some info, but not all of it. And you have no inkling that you are missing something. But if the GC has all the info you need, then no problem.
  • The GC port is read-only. No writes. If you don’t need to write, then no problem.

It’s taken us quite a while to troubleshoot what’s going on here, especially since there is an OS platform divide. There’s also confusion aplenty in how TLS relates to SSL. 🙂

We initially believed that OpenSSL changed the default negotiation version to SSLv2. And that something about the Windows implementation of SSLv2 is incompatible with the OpenSSL implementation. Obvious workarounds based on that belief are forcing the unix client to choose SSLv3 and turning off SSLv2 on the Windows server, both good outcomes outside of this issue.

We’ve been deliberate in not jumping to turn off SSLv2 on the Windows servers because the impact isn’t clear. http://support.microsoft.com/kb/245030 talks about how to go about doing that.

For the unix client —HTTPS—> IIS case, we’ve successfully had the client choose SSLv3, and resolved those incidents.

For the unix client —LDAPS—> AD case, we had more problems, mostly because openldap adds some complexity.

After much hair-pulling, we finally figured out that the openldap client doesn’t handle LDAP referrals after a LDAP bind well–even if they are configured to not follow referrals. Invisible to us, our domain began issuing some new LDAP referrals after we moved the DNS zone for the domain to AD-integrated DNS. The openldap client configuration needed to be updated to use the ldap_set_rebind_proc() function to allow an immediate rebind after connecting and receiving referrals.

The OpenSSL changes were red-herrings that threw us off and SSLv2 had nothing to do with the AD issue.

Hope this helps someone else. Especially folks who are getting the most common advice (which isn’t good advice) on the web for this which is to switch to port 3268 (which doesn’t suffer the same problem because it doesn’t issue those referrals).

Should We Sync Our AD Passwords to Office 365 (Azure Active Directory)?

This is a response I sent to this question on ActiveDir.

—————————–

The usual objection to storing a password in Azure Active Directory (or anywhere that isn’t on-premise) is that you don’t have control of your credentials, and you don’t have the direct ability to enhance the at-rest or over-the-wire risks to those credentials. Let’s examine the logic of that a bit more closely …

For their on-premise services, very few organizations actually go to the strenuousness and periodicity of regulatory audits that Microsoft does for its cloud services. But meeting regulatory auditing doesn’t necessarily mean secure–as folks like Target might like to point out.

If you do sync your passsword, what actually is sent to Microsoft?

Turns out it is a hash of your password hash. So not the password and not even the NT hash.

If you don’t sync your password to AAD and only use federated authentication, do Microsoft’s cloud services ever have your password? Absolutely–yes. If your users use any of the various fat-clients to access Office 365 services, those fat-clients don’t support the security token protocols needed to do federation natively themselves. So they send the password over the wire to the O365 service. The O365 service proxies the federated authentication for the client–getting a federated token with your on-premise STS (or IdP) and using that token to get an AAD federated token it can use to access your O365 content and then send that content back to your fat-client. There are very few customers I know of that aren’t using any fat-clients with O365–so a very large number of users are currently sending their password to Microsoft over-the-wire. That isn’t quite the same as the at-rest credential risk, but most folks seem to gloss over this issue. I believe Microsoft is working on extending the fat clients they own, but they don’t control all fat clients, so this issue will likely remain as long as you have non-Microsoft based clients (e.g. iOS). More folks seem to be familiar with the MFA “app password” issue–which comes from exactly the same client protocol support issues.

So to summarize, there is no option that is “safe” if you define safe as your password doesn’t leave your on-premise organization. There are only options which may or may not meet your organization’s risk management stance. If that stance is that you can’t have at-rest credentials off-premise, then DirSync password sync isn’t for you.

A final thought: our organization had the same sort of initial reaction to storing credentials off-premise. But we’re now thinking about sticking a domain controller in an Azure VM–for a number of reasons that include reducing network traffic back to on-premise for Azure based VMs and to improve our geo-redundancy/business continuity stance. And in a year, we’ll probably also consider sticking a DC VM in Amazon EC2.  Bottom line: business needs often trump overly stringent security principles–and while security principles are nice things, it’s really all about risk management.