Builtin groups in windows
I just spent several hours working on a buggy OWA problem that presented itself as a “440 login timeout” issue. If you’ve ever spent time trying to repair the 440 login timout issue, you’ll know that it is pretty straight forward. You simply re-sync the IUSR_Machinename and IWAM_machine account passwords, run a couple scripts and your good to go. But what if that doesn’t work?
I found a million articles that all said the same thing – iusr/iwam passwords out of sync. That wasn’t it. I started to poke around more, and noticed that there were several rights that were never assigned correctly. I thought that was pretty odd, so matched up the rights with my own SBS 2003 server, and ….. it didn’t work!!! Frustration is now setting in. This actually was over several days of working on it a few hours each day.
So today, I’m poking around, digging inside of IIS and running Process Monitor from Sysinternals/Microsoft. And darn if there it is in plain site – the user I’m trying to login with doesn’t have read rights to the folder. I check, the DOMAIN\USERS group certainly has the proper rights. I try again, same result. I make a couple other changes, same result. Finally it starts to sink in…is the Users group setup right? The Users group is a default ‘Builtin’ group to Windows. Its setup at the time of install and youre really not supposed to monkey with it. So why would it be wrong? Well, that in itself is a long story.
So I finally take a peek at the contents of the DOMAIN\Users group on the clients server as compared to my own server. HOLY COW!!!! The Users group was made up of about 6 standard users. It was completely devoid of the default groups. A healthy Users group should look something like this:
<!– /* Font Definitions */ @font-face {font-family:”Cambria Math”; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:”"; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:”Arial”,”sans-serif”; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} –>
Their Users group didn’t have any of those three objects in there, but instead had 7 individual users inside. So deleted the users that were present, and matched my own server and what do you know – OWA, OMA, and RWW all work like a charm now.
So the moral of the story is, don’t change the default Builtin groups unless you have a really good reason – and then don’t do it. Its easy enough to build the groups that you need around the builtin groups and get the desired result. Its not advisable to modify the default groups in any way. They are there for a reason, and there are services, and applications that depend on them being setup in the proper way. I took it for granted that the Users group would be the correct group from the gate. Thats a mistake I won’t make again. From now on, when debuggin any rights type problem, I’m going to be checking to make sure that the groups listed have the proper objects in them. This is the result of non-admins doing admin work on a server. So be sure to check that what you think is right – really is right. Might save you some time – it would have saved me some time.