DCs, time event 142, w32time, and group policy

Over a year ago, we applied a fix related to this on our domain controllers because of intermittently reported client problems. This fix was the most significant finding out of Microsoft AD RAP as a service engagement that we had.

Turns out that down in the deep details of the time settings there’s a lot that can cause problems. And Microsoft deployed poor values for many of those settings for prior OSes, some of which got encoded in the default group policy values. We turned on those group policy settings back when the values were really bad, and of course, those bad values were still in place because nothing will automatically change an existing GPO setting.

Here’s a table summarizing the craziness:

2008R2 Admx Defaults 2008 / 2008R2 DC Default* 2008 / 2008R2 Member Defaults 2003 Adm Defaults 2003 DC Defaults
FrequencyCorrectRate 4 4 4 4 4
HoldPeriod 5 5 5 5 5
LargePhaseOffset 50000000 50000000 50000000 128000 50000000
MaxAllowedPhaseOffset 300 300 300 300 300
MaxNegPhaseCorrection 172800 172800 4294967295 54000 4294967295
MaxPosPhaseCorrection 172800 172800 4294967295 54000 4294967295
PhaseCorrectRate 1 7 1 1 7
PollAdjustFactor 5 5 5 5 5
SpikeWatchPeriod 900 900 900 90 900
UpdateInterval 100 100 30000 30000 100
AnnounceFlags 10 10 10 10 10
EventLogFlags 2 2 2 2 3
LocalClockDispersion 10 10 10 10 10
MaxPollInterval 10 10 15 15 6
MinPollInterval 6 6 10 10 10

* These are the settings you want on you DCs as they are the OS defaults for a DC

On your DCs, you want to apply what’s in the column labeled “2008/2008R2 DC Default*”. To correct our problem, I turned off all the GPO time settings. Then I turned them back on. Then I fixed the only setting whose (GPO) default value doesn’t match the OS default value for a DC (PhaseCorrectRate).

This fixed all of the time events being raised in our domain.

YMMV, but I expect this will likely help quite a few folks.

Windows Firewall + PowerShell + Group Policy = Wonderful


Last year I did some work around putting together a group policy for the UWWI servers that restricts who can access them to the current definition of the UW Network.

Group policy allows you to define configuration settings once and apply them broadly. And what better application than the Windows Firewall rules that are so crazily detailed and finicky? Who likes to set local Windows Firewall rules? Yuck.

James Morris tipped me off that there were some PowerShell cmdlets that would help me. And he was absolutely right … there was one which really saved a massive amount of time in defining the rules that went in the GPO.

Here are some breadcrumbs that should allow you to put something similar together yourself.

The UW-IT NOC has this document defining the UW Networks: https://wiki.cac.washington.edu/display/UWNOC/IP+Address+Space+Usage

Note that includes both IPv4 and IPv6. And Windows Firewall handles both.

So then you do something like this:

PS C:Windowssystem32> $IPs = @(“″,“″,“″,“″,“″,“″,“″,“″,“″,“″,“2607:4000::/32″,“fd73:a9bd:11bb::/48″)

Then you create your group policy object. Let’s say I created mine in the Dogfood domain, with a name of “uwit: UWWI firewall test”.

You then do something like this:

PS C:Windowssystem32> set-netfirewallrule –DisplayName “Windows Remote Management — Compatibility Mode (HTTP-In)” –RemoteAddress $IPs –PolicyStore “dogfood.netid.washington.eduuwit: uwwi firewall test”

This adds a firewall rule to the GPO for WinRm that restricts traffic to the IP networks in the $IPs variable.

If you pull up the GPO in the GUI, you’ll now see that firewall rule in the GPO. Nice!

The next trick is figuring out which rules you need to add, and that really depends on the box and how tight you want to configure it. On thing to consider: you might go with a course grain approach, restricting TCP & UDP & ICMP traffic, and skip the fine grain approach of delineating all the individual services.

Want to read up on the Windows Firewall with Advanced Security? See http://technet.microsoft.com/en-us/library/cc754274.aspx. If you do dig into it and go the more fine grain route, make sure you understand the Windows Service Hardening type of firewall rules. These are rules defined by the product team (or 3rd party apps/services) and can’t be removed easily. In other words, they are on every box that has the Windows Firewall service installed, and **regardless of whether you have the Windows Firewall on or off**, they exist and are active. And yes, you read that right–there are firewall rules which are active even with Windows Firewall disabled. These
Windows Service Hardening rules are designed to only allow the services to accept traffic from the network sources the service is designed for.

Presentation decks for NTLMv1/Turning off Legacy Stuff and Azure AD

I’ve given a couple presentations over the last couple months. Here are links to the slide decks and webinar:

Turning Off NTLMv1 or How to Approach Turning off Legacy Technology given at Microsoft Redmond campus for Windows HiEd 2014 Conference. Or see the archived Webinar (requires installation of Adobe Connect add-in) given for the Internet2 IAM Online forum.

Office 365 Identity aka Azure Active Directory given at Puget Sound SharePoint Users Group.

Turning off NTLMv1


Some of you may be stuck in the uncomfortable position I was in (until recently) of having an AD environment that still permits NTLMv1. If so, you probably have done a little research to figure out what might break if you turned it off, but having been there, I know that you have found very little online that is detailed or even much in the way of resources that would allow you to move forward.

To be clear, having any NTLM turned on is not recommended–see http://msdn.microsoft.com/en-us/library/cc236715(v=PROT.10).aspx, where Microsoft says ““applications are generally advised not to use NTLM.” But many of us can’t completely turn off NTLMv2 quite yet (mostly because of Microsoft applications that don’t follow Microsoft’s own advice), but probably can get rid of NTLMv1, which is more heinous (than NTLMv2) in terms of the risk it poses. If you need any additional motivation, take a peek at www.cloudcracker.com, with its NTLMv1 rainbow tables available for any individual to use to crack a NTLMv1 hash in milliseconds.

I’ve got two resources to share with folks who want to turn off NTLMv1 but aren’t sure how to proceed.

First, I’ve got a document that lists known problems and potential workarounds. See https://wiki.cac.washington.edu/x/knhhAw for that.

There’s a bit of background reading noted at the top of that document which is recommended for understanding the architecture and relevant settings. The NTLM referrals bit noted there is particularly important to understand, and it has a significant consequences on where NTLMv1 events are logged (hint: only at the initial server the client contacts), as well as where the LMCompatibilityLevel settings actually matter (hint: for the “server” aspect, turning off NTLMv1 on a domain joined computer doesn’t mean anything except to the local user accounts of that computer). If you don’t understand that bit, you will make the mistake I made in the summer of 2013 when I turned off NTLMv1 on our domain controllers because there were no NTLMv1 events on our domain controllers, and then had to roll that change back when lots of people still dependent on NTLMv1 couldn’t access various services.

Also let me highlight a couple significant potential gotchas within the known problems list:

  • Non-Windows browsers don’t support NTLMv2. To my knowledge, there is only a single exception to this statement: Safari on MacOS with an obscure Samba setting. You can find more details in the document above, as well as various workarounds we came up with. This led me to realize that for IIS, Integrated Windows Authentication is a dead end (b/c very few folks actually get Kerberos working on those non-Windows clients) that I should actively discourage within my organization.
  • IAS/RRAS/MS-CHAPv2 & the native MacOS VPN client. The native MacOS VPN client doesn’t support NTLMv2. Only known workaround is a 3rd party VPN client.

If anyone has additional known problems/workarounds they’d like to contribute to this document, please let me know & I’ll add them.

Second, we have a PowerShell script we created to parse the security event log for the important bits from NTLMv1 events. It can be used remotely. See https://wiki.cac.washington.edu/x/cg7RAw for that. We leveraged this extensively to identify misconfigured clients which we then contacted.

I hope this info is helpful—I know I would have really appreciated this kind of info back when I first started down this road.

Microsoft’s JIT approach revealed

Below you’ll find a link to a TechEd Europe session earlier this week.

I just finished watching the 2nd half, which is much more interesting than the 1st half (which presents all the problems we all know about). Microsoft has finally revealed their planned just in time administration (JIT) approach in broad strokes.

Some of the major points:

  • Next version of Windows will have capability where group members can have a TTL that AD automatically respects (AD has had TTL capability for a long time, but this is the first time I think anything has used it)
  • There is a new forest trust type for admin access. Very little said about this
  • There is a concept of a bastion forest. The purpose here is twofold:

a) isolate your elevated account risk

b) have a known place of goodness (i.e. you may already have bad actors in your forest that you don’t know about)

  • There is some newly extended capability leveraging sidHistory such that you can now stick the SID of well-known groups on objects (this is key to allowing the bastion forest accounts/groups to “own” objects in your existing forest)
  • Next version of Windows will know that when it goes to issue a logon token, the TTL of that token should be constrained by the smallest TTL of your security group memberships
  • There are capabilities in MIM.vNext (was FIM) that permit workflow behaviors such that pre-defined “candidates” can self-elevate themselves subject to approval workflows you design and TTLs you specify
  • A key point: you don’t need to move any of your existing environment to Windows 10 to take advantage of this new goodness. You deploy a new Windows 10 forest, setup the elements required to support the stronger access management scenario you need (in that new forest), map them to your existing groups, and empty those existing groups. At that point, no one has access by default, and everyone has to use the JIT mechanism.


I’ve gotten a couple “huh?” sorts of inquiries related to my parenthetical comment above about how AD has had TTL capability for a long time. Mostly about how Microsoft might get something like this to work and whether this TTL stuff happens in AD or MIM. My educated guess is the TTL stuff happens in AD, not MIM.

Here are a few breadcrumbs to allow you to get a handle on this yourself. 

entry-TTL attribute http://msdn.microsoft.com/en-us/library/ms675669(v=vs.85).aspx

dynamicObject (auxiliary) object class http://msdn.microsoft.com/en-us/library/ms682219(v=vs.85).aspx

If you aren’t really into schema, I can’t say I blame you, but you are missing out on understanding a bunch of details. An auxiliary class is one that can be added to an existing directory object. In contrast, a structural class is the class that must be specified at the time of creation of the object. The structural class determines a bunch of things e.g. what defaultSecurityDescriptor the object has. An auxiliary class is typically used to “add” capability without the permanent overhead of modifying an existing structural class. Another important detail here is that you can “layer” (or inherit) structural classes on top of each other—the most common example of that is the computer object class layered on top of the user object class (and you can layer many times, e.g. the gMSA class is layered on top of the computer class).

Now, with those breadcrumbs, the only real mystery to me here is how Microsoft managed to take these existing mechanisms and get them to apply the “automatic deletion” not at the object level as is currently the limit of this existing AD mechanism, but at the attribute level.

In other words, today, you could add a dynamicObject class to any group object and set an entryTtl value. When that TTL expired, the group would be deleted. And there are likely use cases for that scenario (automated clean-up of the group sprawl if the owners don’t “re-authorize” keeping the group around), but that’s different than the use case here where one value of a multivalued attribute (member) on a group object gets deleted when a TTL reaches zero.

So put another way, assuming my educated guess that AD is performing this new group member TTL capability, then there’s some real neat stuff here under the covers. And that neat stuff may be highly relevant to a bunch of other use cases. I’d have to reflect on this, but I can imagine there are use cases where you’d want some other attribute’s value to expire after a period of time.


markwahl (@markwahl)
10/29/14 3:42 AMTechEd Europe: Privileged Access Management for Active Directory (Channel 9 recording) channel9.msdn.com/Events/TechEd/… #tee14

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.

Posted in Uncategorized | 1 Reply

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.

Active Directory Naming Attribute Restrictions

Last week someone asked a question on ActiveDir which many folks appreciated my response to. I’ve summarized the original question and included my response here for future reference.

Where should “prefix” words (Tussenvoegsels) in a name be stored in Active Directory? And how do I reflect cultural differences in names? For example, “Johannes van der Waals” vs. “Johannes Van Der Waals”.

The problem space here is bigger than you’ve outlined. It’s my understanding that there are cultures where the surname is presented first. There are also important name suffixes such as Jr., Sr., II (the second). As well as less important name suffixes. And name prefixes that you may consider important like Dr. There are also some regulations that may limit your ability to actually publish name data–in my sector, FERPA restricts our ability to publish student names when the student has blocked that. Case sensitivity is also a relevant factor in this space. And then there’s the issue of legal name vs. preferred name, which can be a highly political issue when transgender issues are taken into account.

I’d note that the LDAP specification includes support for attribute options. This is the idea that the attribute value might have different values depending on the context desired. It’s like a multi-valued attribute, but each value has additional context that “labels” when that value has meaning. And LDAP clients can request the right contextual value. In the context of this problem, imagine the clients could request the “Belgian” option of the displayName. Or the “Dutch” option.

From a data modeling perspective, it’s much cleaner, and for example, it’d be a much better way to store a bunch of things in AD than what various product teams ended up with. Take for example, the displaySpecifier excerpt I sent earlier this week:

attributeDisplayNames (85): co,Country/Region; c,Country/Region Abbreviation; mSDS-PhoneticCompanyName,Phonetic Company Name; mSDS-PhoneticDepartment,Phonetic Department; mSDS-PhoneticDisplayName,Phonetic Display Name; mSDS-PhoneticFirstName,Phonetic First Name; mSDS-PhoneticLastName,Phonetic Last Name; distinguishedName,Distinguished Name;

An attribute option would have been a cleaner way to represent this data, instead of asserting an arbitrary delimiter of a comma to denote the data relationship. The Exchange product has a *lot* of examples in AD where this would be a better data modeling choice too–for example, the proxyAddresses attribute.

But AD doesn’t support attribute options. 

So why did I bring it up? Well, I know a lot of places that use other LDAP directories to master their name data. And those that have tackled these harder issues leverage attribute options to accurately represent the name data in all these various formats.

And using an arbitrary delimiter—mimicking what Microsoft has done in a couple cases–isn’t really a good option here.

There’s another AD limitation too. By RFC, sn is supposed to be multivalued. But in AD, it’s single valued! So with that attribute, you can’t even invent an arbitrary scheme to represent the various versions of the data you’d like to store. 8–10 years ago, when I pressed Microsoft PMs hard on this issue, I was told that yes, they recognized they screwed up, but there was no way they could fix it because it’d cause too many problems.

I’ve just talked about a bunch more challenges and not provided any help moving forward—but I think that’s actually helpful, because context is important. 

From a high level, I think you need to recognize that your best outcome is providing something pragmatically useful because the underlying product hasn’t given you the flexibility required to solve all these issues ideally. You do have the option of creating custom attributes, recognizing that none of the MS products that integrate with AD user data will leverage your custom attributes (I think Exchange is partially an exception here). Maybe that’s OK, and you use the displayName attribute to roll up all the bits of name data–both from the standard schema and your custom schema. But you’ll need to find a pragmatic compromise for the displayName value and the sn value–as those are single-valued and you really have no flexibility with those.

Diving deeper into the mechanics of which parts of the name data you store in which attributes, I’d bet there is a large diversity of choices taken by each AD deployment. The key here will be to make a decision for your implementation, document it, and then implement it.

Another thing to keep in mind when doing the data design is the ANR attribute set. The ANR attribute set by default is: givenName, sn, displayName, RDN, legacyExchangeDN, physicalDeliveryOfficeName, proxyAddresses. The ANR is a common search built into a lot of the MS integrated products, and this may influence where you decide to stick data. One thing to keep in mind about the ANR search is that if the ANR search has a space in it, it will break up those substrings and try both of those substrings against givenName & sn (in addition to all the other attributes). In other words, the ANR search makes it less important how you choose to format the displayName value. The ANR may influence your data design because if there’s name data you want to store, but most folks wouldn’t want to search on it, then you’d want to avoid putting it in that set of attributes. Or on the other side of the coin, maybe you’ll want to change the ANR attribute set from the default so more attributes are searched by default.

My AD has some name data standardization applied to it. But I have a mess when it comes to the source systems that supply the name data–and merging all those data sources. The source systems gave very little thought to these kinds of issues, in some cases have case insensitive data, there are a mix of legal and preferred names to choose from, and I have to deal with the FERPA issue I mentioned earlier. I’ve got a bunch of code to wrangle all of that, but to be honest, maintaining it and having to live with the limitations is the worst technical part of my job. For the past 5+ years, I’ve been pitching a different approach which ditches all of the source systems, and creates a new single source of preferred name data. That new single source allows the users to assert their preferred name, but applies a set of name data rules at the point of input to ensure consistency and prevent deviation that is too great from the various source systems. This eliminates the need for the code I maintain by leveraging input validation, and eliminates the complexity associated with wrangling all the various source systems.

I hope all of that is helpful in some part.