Search This Blog

Thursday, January 24, 2013

Group Policy Objects not applying and Domain Admins missing from local administrators group on Server 2008

Recently had this issue, where I had added a server to a domain, everything had gone smoothly, or so it seemed….

The server had been running for a while as a standalone server, and had be doing so successfully and uneventfully.

So now I had added the server to the domain, I could log on as a Domain Administrator and everything seemed good. The problems started when I tried to deploy GPOs, other machines in the domain were happily accepting the GPOs and applying them.

The GPO in question was to add a group to the local administrators group, this was to do with an external trust that had been setup. I discuss this here

In addition I noticed that I could not remotely browse to shares on the server, now this issue I cannot guarantee it was not there before (I don’t think it was as I am sure it would have driven me mad earlier).

So I went looking for information in the event viewer… strange no errors. So I then began looknig for logs that would help me with trying to resolve this issue. I found that there are a number of logs you can switch on which will provide more information. I found this page on the microsoft site which lists a lot of logs

http://technet.microsoft.com/en-us/library/cc775423(v=ws.10).aspx

Now I choose to enable only one

Group Policy core (UserEnv) and registry CSE

I found I had to change the registry entry and then reboot the server, it seems to imply you can just run gpupdate but that didnot work in my case. Once the machine had rebooted i also found the log file was not called userenv.log but was called gpsvc.log (but the location was correct, C:\Windows\debug\UserMode\).

On inspecting the log which has a ton of information I found one interesting line

GPO <PolicyName> doesn't contain any data since the version number is 0.  It will be skipped.

This didnot seem right, so I started trying to track that issue down. Now all things this seemed to lead to was about VMs, but this wasn’t a VM…. but I had a feeling an image had been used to create this server. So it seemded to be plausible that the issue was the same thing. Now the problem is to do with duplicate SIDs, I wasn’t seeing any inforamtion (event logs) to say that was the issue, but I was running out of options.

So I ran sysprep.exe clicking the generalise option. Now the server reboots, and of course all settings have been reset. I had to rename the machine back, I had to fix up the networking (teaming had broken) as the network deivces had been readded as different IDs. Now I tried to add the server to the domain (I had to delete the old server listing from the domain controller prior to this). All good. And now looking at the local administrator group the domain administrator group is now appearing and also the group I wanted added by GPO has also been added.

So all of my problems were caused by duplicate SIDs, just wish there was more of an obvious error to point you in that direction.


Share/Bookmark

Event ID: 1 - VDS Basic Provider:-Unexpected failure. Error code: 490@01010004

Had this error on a server, found an article that references Hyper-V which I did not have installed and in addition states that the error can be safely ignored… Lame. Why can it be ignored…

I noticed that the next entry after getting this error on every boot, was the VDS successfully starting.

The Virtual Disk service entered the running state.

On inspection the service is set to manual, so I can only assume that the first request to use the VDS cause the initial error but this request also has the server start the service. So I tried setting the service to start automatically and now the error is gone.

So again no explanation but a way to get the error removed from your logs…


Share/Bookmark

Wednesday, January 23, 2013

Setup Collabnet Subversion Edge Server using an existing SVN repository and using LDAP to Authenticate against Windows Domain.

Recently had to setup an SVN server, this svn server was to house an existing svn repository housed on another server. The authentication on this server was setup with the file method.

As part of the move we wanted to utilise the domain resources as we tried to consolidate user management across our applications.

So we chose the latest version of Collabnets Subversion Edge Server 3.2.2 (x64) to run on a Windows 2008 R2 server.

The R2 server was a clean server, with no IIS installed, therefore the setup of apache, which subversion edge relies upon would be less of a pain (no port changes Smile).

OK, so we ran the installer for Subversion Edge, which was painless, it detected that Java was not installed on the server and it installed Java. It then installed the Subversion Edge server product.

On completion of installation we just left the tick boxes checked that fired up administration portal. By default this will be http://localhost:3343/, the default login is admin with password admin (this can be easily changed).

The repository itself was just copied over from the source server (running svn 1.5), into a folder on the new server using windows explorer. Nothing fancy, no svn dumps etc…

Once logged in you are presented a simple interface, with the status of the apache server given right in the centre. If it is stopped, there is a start button and vice versa.

Under configuration on the right, I went into server settings and added the location of the svn repositories and dump folders. I changed the repository setting to match the location we moved the repository into and the dump folder

D:\SVN\Repositories

D:\SVN\Dumps

I saved these settings, and then went to Repositories, which is on the menu at the top of the page. Here I clicked discover and the repository I copied over appeared in the list.

Ok, so by default you should now have anonymous access to the repository, this is a good spot to check things are working as expected. You can get to the repository from other machines.

Subversion Edge Server runs apache, and it uses http protocol for the client server connection protocol. It does not setup svnserve.exe (although this executable is installed in the csvn folder and can be configured if you want), which means that the svn:// URLs cannot be used in a standard setup, you will therefor be using http URLs. In the repository list, mentioned above, it gives you an example svn client checkout command, which includes the http URL to the repository. The command will look something like below.

svn checkout http://<hostname.domain>/svn/<SVN_REPOSITORY_NAME> <Physical Folder Name to checkout into> --username=admin

This initial process was pretty painless as far as I was concerned, now we came to the LDAP setup. I have only had to use LDAP very sparsely in the past so terminology was vaguely familiar but I found the documentation very limited, in helping you understand what to put into each of the boxes on the authentication page.

So lets go to the authentication page (under configuration menu header on the administration section, in the admin portal )

Now it has to be said, I am far from an expert in any of this, and if you need to add encrypted connectivity to the LDAP – Domain communications then you will have to find that on your own, for our purpose unencrypted comms is fine.

So I will go through each of the settings on that page and try to explain my understanding. Following that I will list out the settings I used (with something's changed for security :o) )

Anonymous Access: Allow read access to anonymous users.

Ok, pretty self explanatory if you want to allow anonymous users to be able to read the repository then check this.

Convert Usernames to Lower Case: Convert usernames to lower case for access rules.

Now I believe that this is good for when you want to start apply rules to control repository access. I have this checked.

Authentication Methods: Local authentication against an htpasswd file along with other providers.
Authentication Methods: LDAP authentication against an LDAP server:

So again, pretty straight forward, first one is to use the old method and a local file. second option is to use LDAP. You can use both, and I think it checks the file and then LDAP. In our case I just want LDAP so htpasswd is unchecked.

LDAP Security Level: None

Ok, now this can be changed to secure the LDAP comms from client to server, I didnot set this so I can’t tell you what needs to be done.

LDAP Server Host: <domain>

So here we come to some juicy bits, now here you can specify one dc directly, and if you do that it will affect the port you use (next option). However assuming you have a modern windows domain with multiple DCs then you probably just want to set this to the domain, so it can use any dc running LDAP.

i.e. if your fully qualified server name was something like server1.domain.com, then you would place domain.com in this setting.

LDAP Server Port: 3268

Hint: try 3268 for Active Directory servers

OK, I think initially this was set to 389 port, which is the correct setting if you want to just use a single LDAP server (see LDAP server Host above). However if you want to utilise the functionality of any of the dcs in the domain then set this to 3268.

LDAP Base DN: CN=Users,DC=domain,DC=com

Example: OU=Users,DC=xxx,DC=yyy,DC=domain,DC=com

Now this setting will depend on how you have your Active directory configured. But a default AD setup will have Users in an CN called Users. What we are setting here is the location subversion Edge will query when looking for users.

A good tool to get DNs (Distinguished Names) from your active directory is ADSIEdit (comes with windows). You can browse to the item, right click properties on it and then look for Distingusihed Name, you can then copy it out.

LDAP Bind DN: CN=<svnLDAPQueryUserName>,CN=Users,DC=domain,DC=com

Now this setting is specifying the user that Subversion will impersonate when sending the query to the LDAP server. Now you can setup a specific user for this purpose and assign the necessary rights to the user to query the directory, so we don’t have to use some form of administrative account. So in Active Directory create the user and password that you want to use for this purpose. Now on the OU you want to query (in the default case this will be Users), right click the client and select Delegate Control, this will start a wizard.

In this wizard select the user/groups you want to delegate to, then in delegate the following common tasks select “Read All User Information”. This will allow us to use this user.

LDAP Bind Password: <password>

BindDN and Password are only needed if anonymous binding is not supported.

Password of the user we created above. :o)

LDAP Login Attribute: samAccountName

The default attribute is 'uid'. Hint: use samAccountName for Active Directory

Set this to samAccountname to ensure that Subversion is loking for the usernames in the correct attributes.

LDAP Search Scope: Sub

Now this will tie in with the LDAP Base DN setting earlier. we are just telling subversion whether to recurse through sub OUs or stay in the OU.

LDAP Filter: objectClass=user

As we will be authenticating user, it makes sense to try and speed up the searching by starting we are looking for users so thats what we do here.

LDAP Server Certificate Verification: <checked>

Verify the certificate of the LDAP server.

I am afraid I don’t know what this does, but I left it checked.

Console LDAP Authentication: <unchecked>

Allow LDAP users to access the management console

Now I unchecked this, to stop them trying to access the admin console (it will allow them a limited set of usability to browse the repository in a web page). This is up to you but for me this was not needed, the developers use tortoisesvn which has a browser.

Console LDAP Authentication Helper Port: 49156

Used to facilitate LDAP authentication to the console with the above settings. Normally, no change is needed here.

Left this one as default. 49156, not sure what it does…. :o)

Ok, and that was it. Saved these settings and then tried to use a windows account. And for me this worked. You don’t need to specify a domain, with the username just the username.

image

image

OK, that was it, but in this current setup any user that can authenticate to the windows domain could access the repository and potentially reek havoc.. ;o)

So how to limit access… This is achieved by changing the access rules in the subversion Edge admin portal.

By default the access rules section, found under the repositories top menu item, will be set to

[/]
* = rw



This is telling subversion that everything from the root level down ([/]), is available to all (*) with read and write access (rw)


Ok, so lets remove access to everyone



[/] 
* =



OK, so now lets add access to our repository




[SVN_REPOSITORY_NAME:/]
windowsusername1=rw
windowsusername2=rw
windowsusername3=r



So here we are saying these rules apply just to our repository at the root level[SVN_REPOSITORY_NAME:/]. You can add more granular control to subsections of the repository by specifying headers like


[SVN_REPOSITORY_NAME:/subsection1/]. 


But in our case we apply at the root level and everything inherits down. Then we are listing the windows usernames with the access we want. user1 and user2 have read access, whilst user3 has only read access.


And that's all folks…. I hope….

Share/Bookmark

Tuesday, January 22, 2013

Moving IIS7+ configuration to another IIS7+ server

We have had to move config from one server to another, and we have discovered a general procedure for achieving this. We were just trying to copy over the applicationhost.config, but found sometimes the application pools would fall over.

Now as you might be aware, the majority of IIS7 website config is held in the applicationhost.config file, usually located in the

<windows folder>\system32\inetsrv\config

folder. There are instances where the config will be configured in web.config files, in the root of the website\virtual directory physical folders. But I won’t go into that here.

You can just copy over the applicationhost.config file to the new server, but you will have problems with passwords as the encrypted machine keys will not match. We need to export from the original sever and import into the new server. You can do this.

aspnet_regiis.exe found here

c:\windows\Microsoft.NET\Framework64\v2.0.50727\

Exporting

aspnet_regiis.exe -px "iisConfigurationKey" C:\temp\iisConfKey.xml -pri
aspnet_regiis.exe -px "iisWasKey" C:\temp\iisWasKey.xml -pri

Copy files to new server.

Importing (use -exp so the keys can be exported again)

aspnet_regiis.exe -pi "iisConfigurationKey" c:\temp\iisconfkey.xml -exp
aspnet_regiis.exe -pi "iisWasKey" c:\temp\iisWasKey.xml -exp

This should allow the application pools to properly function.


Share/Bookmark

Wednesday, January 16, 2013

Add external users to Domain Admins (External Trust)

Recently had to setup a one way external trust between 2 separate domains (not in same forest).

To start with I had to establish dns resolution between the 2 environments, now you can either setup forwarding or setup secondary zones. In my case I decided secondary zones was the way I wanted to go. This enabled me to then setup the outgoing and incoming trusts in each of the domains.

Then I wanted to allow a user in the external trusted domain to be a domain admin, however I soon encountered a problem. There are a raft of rules about what security objects can be assigned to what groups, and to summarise the Domain Admins group is a global security group and as such does not allow for external resources to be assigned to it, there is no way round this using universal groups or domain local groups.

I was banging my head against a wall when I discovered this article, which proposes an elegant solution using domain local groups and group policy objects. In essence we are taking the remote users, adding them to groups and then applying a gpo to add these groups to the builtin/administrator groups.

The full article is here.

http://jasonduffett.net/post/5448151233/administering-cross-forest-domains-with-a-single-login


Share/Bookmark