Information about joeware mixed with wild and crazy opinions...
Not sure how this slipped by me, it isn’t like I am following the NET stuff all that closely but I expect I will hear about the bigger things usually… Anyway, the 3.0 version of the NET Framework is now available. I have no clue what they did for it but I hope they fixed lots of bugs; especially in the DS related areas. 🙂
I was perusing the newsgroups this evening and ran across someone with a “case” issue with logon names in Active Directory. It seems some software he was using required a specific case[1]. Well AD doesn’t case about case… at all. However this person was having a problem changing the case. I looked at it and didn’t see an issue… then Richard Mueller caught on that the poster meant the issue was with the userPrincipalName and ADUC was indeed not letting him change the case…
I tried this and sure enough, on my version of ADUC this was also the case… ADUC 5.2.3790.1830… I fired off a quick note to one of the really good MSFT developers I know who has the most likely chance of getting something done with that problem and fessed up in the newsgroups that yes that appears to be an issue in ADUC, but rest assured it isn’t an AD bug… I then offered a solution…
The solution was to use adfind and admod together to change the userPrincipalNames to lowercase… Previously I might have said this will take a script… However this is actually extremely easy to do now with the latest rev of admod…
Assuming you want to change the userPrincipalNames to all be lowercase across your entire default domain you would use a command sequence like so:
adfind -default -f userprincipalname=* userprincipalname -adcsv | admod userprincipalname::{{.:_lc}} -unsafe
I don’t care if you have 10 objects with UPNs or 10,000,000 this will handle it… Not only will it handle it but I doubt there is a script that could touch it for processing speed regardless of the number of objects that have to be made…
So let’s break this down into its components.
adfind -default -f userprincipalname=* userprincipalname -adcsv
This generates a CSV stream containing the DNs of matching objects combined with the current userPrincipalName, it will generate something that looks like
~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~
“dn”,”userprincipalname”
“CN=_TestUser1,OU=Users,OU=TestOU,DC=test,DC=loc”,”_TestUser1@test.loc”
“CN=ADMINONLY,OU=Users,OU=TestOU,DC=test,DC=loc”,”adminonly@test.loc”
“CN=TestAdminClone,OU=Users,OU=TestOU,DC=test,DC=loc”,”TestAdminClone@test.loc”
“CN=TestEmail,OU=Email,OU=My,DC=test,DC=loc”,”TestEmail@test.loc”
“CN=user\, test,OU=Users,OU=TestOU,DC=test,DC=loc”,”testuser@test.loc”
Next this CSV stream flies across the pipe (that would be the | character) to admod which then executes the following:
admod userprincipalname::{{.:_lc}} -unsafe
First thing off, the -unsafe part simply says no matter how many DNs are read in from the CSV, process them all… You also have the option of setting a specific safety number that you would want to bail out on everything if you exceed with the -safety X switch or you can say do up to X with -upto X.
The other part is the fun part…
userprincipalname::{{.:_lc}}
This tells admod that you want to:
How cool is that? Heck I have been playing with stuff like that for some time now and I still think it is cool. 😉
joe
[1] WHY WHY WHY WHY WHY WHY WHY WHY? If you are a developer and your application is case sensitive for userids…. WHY? Do you really need the ability to have a joe and a JOE as two completely different users?
Do you have PSTs that have duplicate emails in them? I certainly do, well sometimes do… I have a habit of backing up a lot of my files across my various PCs and this gets messy for PST files because Microsoft Outlook isn’t intelligent to properly merge PSTs, it just keeps everything. Quite annoying actually…
So anyway, there is this cool tool from MAPI Lab that I have been using for a long time (years) to do this cleanup occasionally. I upload all of the PSTs back into Exchange in a special cleanup account and then use Duplicate Email Remover to delete all of the dupes… It works extremely great and it is only $15… It really is a great deal. You don’t have to delete the dupes BTW, you can just mark them or move/copy them to a folder…
Check it out…
I just cleaned up some work related PSTs this evening and cleaned up over 2,000 duplicate messages. I am going to go after personal PSTs tomorrow night… 40GB worth… Once I have everything cleaned up and well backed up… very well backed up… I am going to go to Outlook 2007.
joe
As I have mentioned previously, CPAU is an app that I have on the joeware site that is amazingly popular but not something that really excites me and isn’t one the utilities that I really love. It was just sort of something I whipped up to help myself in a couple of cases with a bunch of stuff added in later to help others.
Well now I come to a crossroads, one of the big uses for CPAU is escalation of the security context to do things locally, usually from logon scripts. That isn’t what I had in mind when I wrote it but that is how the program is being utilized by a vast majority of the consumers so that is how people perceive it and as a good ~friend of mine recently mentioned to me… perception is reality. Well after going over my utilities, CPAU, because of that primary de facto use, is the one utility of the bunch of them that has the most chance of being impacted. In fact, it is a 100% chance that it is impacted.
So why did I originally write CPAU? Well I was lead ops guys for the AD in a large company and helped out on a lot of things other than that AD environment so found myself needing to use a lot of different security contexts. I am, of course, a command line guy and from the command line you use runas to start different security contexts. Specifically I would type a command like
runas /netonly /user:somedomain\someuser cmd
and then enter the password when prompted. The runas tool defaults to interactive authentication and I rarely need interactive and usually couldn’t even use it because I was often hitting machines with security contexts that I couldn’t authenticate via the trust path. That caused me to to decide to make an app that was similar but defaulted to a network auth instead… Initially I thought the API I would use would be CreateProcessAsUser… Hence the name – CPAU. In the end though I used CreateProcessWithLogonW so the more accurate name would be CPWLW but that just doesn’t flow like CPAU does… Plus the command line name I type for it is very handy in that it is a left hand character, then a right hand character, then a left hand character, then a right hand character… i.e. very quick to type because one hand isn’t doing a majority of the work, it is split up[1]. While CPWLW fits that same criteria, it is longer and just doesn’t flow. Plus now that I have taken the number one google slot away from the City of Palo Alto Utilities I wouldn’t want to give it up… I watched CPAU grow up the rankings a long time to reach that coveted first hit… And as we all know, whoever has the first hit, well they know the most about that topic don’t they? 😉
For my purposes, CPAU will be just fine as the network cred stuff will still work just fine in Vista. The folks that will be impacted will be the MAJORITY of the user base who use it for logon scripts and local escalation on desktops when their users who are ALREADY running with normal security levels need a bit more kick to accomplish something like maybe a tweak or some software installs or what not. These folks didn’t actually need MSFT to change things to run with least user permissions. They will have the option to just turn UAC[2] off[3] and have things continue working as they are or try to find new ways to do things.
The problem is that when you use CPAU to change the security context, if you change to an ID that has administrative rights but is NOT the builtin administrator ID, the administrator SID in the token will only be used for DENY access, the new process will not actually be escalated in security capability. This kind of defeats the whole purpose of escalating the security context… If you use the builtin administrator ID, happy days, no issue, the account will act like a full administrator and you can do what you want. Personally I thought that was a horrendous idea… We have spent years trying to get people to not use the built in administrator ID because it is GENERIC and you can’t really track what individuals are doing with it and then Microsoft comes along and makes it special to the point that some people will end up feeling they have no choice BUT to use it. Thanks.
The alternate options to use the builtin administrator ID for the enhanced security context is to mark CPAU to be run as an enhanced user which pops the secure desktop to get the permission to do so… Only that also defeats the whole purpose… if the user had those rights, CPAU isn’t needed in the first place.
One might be tempted to argue that CPAU isn’t needed anymore, people should be able to do everything they need to do through other mechanisms. I don’t believe that is true. I expect for at least some time there will be things that folks need to accomplish that they will not be able to accomplish because they can’t put up the mandatory requirements to to use the MSFT methods or they just aren’t willing to pay for other mechanisms from MSFT say like a full SMS setup or what not. There will be old legacy packages that are needed for Critical LOB apps, etc that for some reason or another won’t be able to be repackaged in another way to take advantage of new install techniques, the issues could be technical, political, resource based, whatever, you name it. So there will be people that need in Vista what CPAU gave them in XP.
So I am looking at the problem and trying to work out what I am going to do; if anything. My current vision is a whole new utility called CPAUEx or CPAU+. I have determined ways of pulling things off so people won’t have to jump through the hoops I mentioned above. It isn’t any special hacking or anything, just standard architecture stuff. But it means I have the ability to put something together so folks could use the existing CPAU encoded JOB files and CPAU will perform identically and the process will end up with the exact same rights/permissions it had before. It doesn’t mean whatever was launched will still work because whatever “it” is, could do something else Vista blocks, but it should help out considerably. While I have come up with a plan on how to do it, I haven’t actually decided if I will or not. If I do, I will probably add some other functionality like being able to execute something as LocalSystem and also work in the cases where CPAU didn’t work which was when someone tried to launch CPAU from a process running as LocalSystem (from the scheduler or IIS or some other service). I would also look at using actual encryption instead of encoding and finally… I would also, and don’t get sick, visualize a GUI to configure the JOB files because some folks seem to have a lot of issues with that.
If you use CPAU now, I would be interested in hearing your thoughts. I would also be interested in hearing how much you think you and others would be willing to pay per instance or for an enterprise license of this new utility.
joe
[1] Yes believe it or not, when I make command line tools, I do often think about the typing sequence for the command when naming it… Weird huh.
[2] I dislike the name UAC and user account control… It isn’t very explanatory and it stomps on the name of the userAccountControl attribute which has been around in AD for 6+ years and the user account control field which has been around in NT forever… So now anytime someone says user account control I have to try and figure out of the three things what they are talking about. What was wrong with LUA – Least User Access?
[3] I honestly do not recommend this.
You will have noticed the previous two posts were about Vista changes. Why did I post them? Well because I am actually FINALLY forcing myself to really dig into it and understand how it impacts joeware. Honestly I should have spent considerable time on this before but I will use the excuse of being far too busy with the job that pays for my food and housing…. If I was dedicated to my software business, this would be unacceptable and I would need to knock myself on the head. Since the software business is “on the side” I am not so impatient with myself and less willing to give myself a concussion for not spending time playing with the new stuff… Truth be told, for work I am happy when I get to play with even * 2003 revision level Microsoft stuff, I seem to spend a lot of time working on figuring out Windows 2000 and Exchange 2000 revision level issues… Longhorn and Vista aren’t even words I can utter at work as it just isn’t in the cards in a near time frame for the businesses I work on at the moment.
The reading I have done certainly indicates there is a rather large change in the security posture of the Windows client OS and the same will likely be so with Longhorn. I expect it will piss some people off. I expect that the pissed off folks will fit into a couple of categories
1. People who have already done substantial work to lock their environment down and have come up with good and realistic safe ways for handling management.
2. People who don’t give a shit about how secure things are and just want to get “it done” with “it” being whatever they need to do.
The first set will grumble and piss and moan but will get over it and find new ways to do things and after a month or several months will be just as efficient as they are now. The second set…. I am more worried about them. They will likely look at disabling everything and not work towards cleaning up and doing things “the right way”. If you are in that second set of people[1], I urge you now to start taking security seriously. Just because you have never had a problem, or more accurately you have never detected a problem, doesn’t mean you aren’t having a problem or that you won’t have a problem in the future.
I think it will take a bit for all of us to spin up on the new stuff and beat Microsoft up for any bad/incorrect documentation we find. One the RTM version of Vista is out and you start hitting docs that aren’t correct, I highly encourage you to tell Microsoft so they can fix it. If you don’t know how to get that feedback to them, contact me via my email address and let me know the details, where the document came from (actual URL) and what you found wrong with it and I will look into getting that feedback to Microsoft. I consider it to be extremely important because bad documentation is simply going to encourage people to turn off valuable good security features because they won’t think they are working properly.
joe
[1] These would be the folks who stumbled on this blog, I am sure the folks who regularly read this blog are far more enlightened than this. If they weren’t the type of person who took security seriously, I don’t really much expect they would enjoy reading what I usually have to say.
If you manage, integrate, or develop code for Windows PCs in a business environment; you will want to read this document I am linking to below. I am not sure if it is at 100% yet as there were a couple of things mentioned that I don’t believe were correct, but it should be required reading for anyone who will be managing, integrating apps for, or developing code for Vista or Longhorn…
The summary is that there are a lot of changes in the basic security model assuming you don’t go and turn off all of the security features and I really recommend that folks NOT turn the features off. These security features are what WE have been telling MSFT they needed to do for some time. Sure they may not be what we expected but they are what we asked for…
If you just throw Vista out there on the desktops you will probably run into quite a few of your current admin/management practices/processes/procedures that just don’t work any more. This doc will start to help you understand why.
http://www.microsoft.com/downloads/details.aspx?FamilyID=ba73b169-a648-49af-bc5e-a2eebb74c16b
Microsoft Standard User Analyzer – This tool will help you identify issues in programs that make it so an application can’t run as a normal user. Very detailed. This was floating around for some time, I recall seeing one of the early revs of this tool several years ago at a special Microsoft Security MVP summit and we received copies of it. It is much enhanced and I think could be very useful for folks looking to locking desktops down or who are going to deploy Vista or if you write an app that you want to distribute.
http://www.microsoft.com/downloads/details.aspx?FamilyId=DF59B474-C0B7-4422-8C70-B0D9D3D2F575
Microsoft Application Verifier – This tool is used to help do runtime verification of unmanaged code to find sneaky little programming issues.
http://www.microsoft.com/downloads/details.aspx?FamilyID=bd02c19c-1250-433c-8c1b-2619bd93b3a2
Is likely going to kill us for future IT support. Well at least those of us in the US, Canada, Germany, UK, and other Western Europe countries.
Right now we seem to be in a phase where we are shipping low end tech positions to India or Costa Rica or Mexico or various not so well to do Slavic countries. Folks are doing this because it is cheaper right now.
Up front this is already hurting us just from the standpoint of customer service and pure understanding. I haven’t really heard anyone saying anything good about any experiences of getting someone in India to help them with their computer issues – honestly, it is a standing joke anywhere you go. Be this in the home market with Home PCs or the business market. Trying to get a point across at times can be an exercise in pure frustration as cultural barriers crop up and get in the way with how things are described and understood and not to mention accents and word usage.
Of course, companies that take on IT support for non-IT based companies or even IT orgs within non-IT based companies really don’t have much choice in the matter, they are told to make it cheaper and cheaper and the way they find to do this is to boot some American/Canadian/Western European/Englishman in a Level 1 or Level 2 position out of a job and give it to four people from some low cost support center who are cheaper together than the one person who got booted. Even if there were a more expensive “we won’t offshore the support” option for companies to choose, most wouldn’t choose that option because they want it to be cheap.
Long term this is where I see this going
1. The companies where people are getting booted out of lower level positions for offshore resources are going to find that they will become more and more dependent on these low cost centers until such a time that they will have no onshore resources at any level up through the highest tech levels. Why? Where do the high tech level people come from? You don’t train them… They are low level tech people that grow into higher level tech positions from all of the experiences they have gone through. If all of the low level people are offshore, eventually they will grow into higher level tech people and the onshore higher level tech people will retire or even be replaced by the still at this point cheaper offshore folks. Eventually, you hit the no onshore technical resources at any level. As one friend mentioned to me a few months ago… Look at what happened in the steel industry between the US and Japan. Initially Japan just did the low end stuff that Americans were happy to foss off… What did Japan do later? Took that experience and started producing high end stuff at a cheaper price. As the US steel business suffers the Japanese steel prices can come up and eventually overtake any high price points the US steel ever had with newer higher price points because we have no options.
2. The cost of the offshore resources is going to go up. It will stay just below what it is for onshore resources right up until the point that it becomes a fact that there are no onshore resources and then all of those companies pushing in that direction will get a nice surprise.
This problem is due to big business and politics and the lowest cost now mindset. I think currently the laws etc are such that it says, sure go ahead, do this, it is a great idea! But then the politicians passing these laws don’t have anything to worry about, in fact most everyone in Washington can feel pretty safe, the government stuff isn’t allowed to be offshored. How about though, and I say this facetiously but man it would be fun, we offshore our senators, judges, congressmen, president, etc? I expect if that were a reality, laws would be different.
And if you don’t want to do this through laws, how about we offshore corporate executives… Sorry Steve Ballmer/Bill Ford/Samuel Palmisano/Mark Hurd/Richard Wagoner/etc, we found 50 people in Costa Rica who will do your job at a cost per year that is less than you spend on coffee for your personal household in a day… In fact, we can get everyone in the country for less than we pay you per year… If something like that happens I expect companies wouldn’t be in such a rush to push jobs offshore into low cost centers.
The thing that confuses me though is that our politicians and heads of corporations can’t really be that stupid as to not see what is going to happen down the road can they? Or are they?
joe
P.S. Note this isn’t a racial thing. I have several very good very intelligent friends who came here from India. But they were so good, they left India and came to America or England to get a job because they could. When I have asked them they have also said not so good things about the support (and the people providing it) coming out of India…
Gary Olsen wrote a very good, IMO, article on virtualizing domain controllers for SearchWinIT / TechTarget. You can see it here
He touches on a lot of the points and pitfalls around doing this…
In general, I am not for virtualizing DCs in production except in very specific well defined cases. Those specific cases primarily being lag sites which you know will not receive much if any real use and sometimes I can be convinced that you should do it in WAN sites that are small. I like virtuals in test because you often don’t get much hardware for test and this fits the bill and if it gets really whacked, you start over…
The reasons for not giving a general thumbs up comes down security, the belief that the tech isn’t complete there for it yet[1], and mostly because I don’t think Windows admins in general are really good enough yet. There definitely are exceptions but I am finding more and more that companies are trying to treat AD like a commodity or utility and just tossing any old Windows admins at it and that works fine right up until it breaks; then you are in a massively bad spot. I have seen ADs run by really good people that have had issues, ADs run by folks not truly knowledgeable and focused on AD and using virtualization is, again IMO, a recipe for disaster.
A question I find many folks who otherwise seem relatively knowledgeable about AD seem to have not thought about with virtual DCs is what are the recovery plans for a failed host? A failed guest is easy, clean up AD and redeploy a previous file where the DC wasn’t a DC and promote it or do a systemstate restore. But a failed host…. Every plan I have seen yet IF there was a plan at all[2] was to recover all of the host DASD from tape… WHOOPS. No, that won’t work, the plan should be rebuild (or recover from systemstate backup) every virtual DC on that host… Why? Because it is the same case of if you lost just a guest OS DC… You know why you don’t roll back to a previous file in that case right? The lack of understanding I have encountered in even allegedly well informed people that you also do that for a Host failure is a bit disturbing to me when I run into it because it calls into question if people really understand or are just regurgitating what someone else said. That can be difficult to ascertain in people who believe what they are saying and say it with authority to those who don’t know.
AD is a distributed application with very critical interconnections, you NEVER roll it back unless you have but a single domain controller or ADAM instance. Failure to follow that guidance can lead you down a very evil path of data divergence and you don’t want to go there.
joe
[1] As Gary mentions, your big use items on DCs is disk and memory and that isn’t what virtualization is good at sharing.
[2] Why do people think that a normal server can fail but can’t imagine a virtual host failing?
[joeware – never stop exploring… :) is proudly powered by WordPress.]
