Domain Controllers

Archived Posts from this Category

16/05/2011

netlogon error 5602 in Windows 2008

Posted by Robert under Domain Controllers, Windows
Leave a Comment 

I upgraded the TNS lab this past week from Windows 2008 to Windows 2008 R2, including replacing the 4 Domain Controllers (rather than upgrading). It gave me a chance to review the procedure for moving a Certificate Server to a new system, which I hadn’t done since 2005. For those who haven’t tried, the procedure for moving a Certificate Server is reasonably well documented at the Microsoft Support site here: http://support.microsoft.com/kb/555012. The part of this that’s especially tricky, especially in our lab, is the renaming of the DC.

In our lab we have an empty forest root, as per the old (Windows 2000-era) Microsoft recommendations, to match several large customer environments. Because it’s a lab, and no clients connect to it, we only have a single DC. I snapshotted it as a backup, and went through the procedure to rename a domain controller, also well documented by Microsoft, this time at TechNet.

For review, the procedure we planned to run was:
netdom computername dc04 /add:dc01.lwtest.corp
netdom computername dc04 /makeprimary:dc01.lwtest.corp
shutdown -r -t 0
netdom computername dc01 /enum
netdom computername dc01 /verify
netdom computername dc01 /rem:dc04.lwtest.corp

I’m still not sure what caused it, but in this case, this command failed:
netdom computername dc04 /makeprimary:dc01.tns.lab
At this point, I couldn’t make the old name primary again (I would get an “Access Denied” error), so I rebooted to see which name had taken. And that’s where things went bad.

When the DC came up, we were getting this error: Netlogon EventID 5602. Source: NETLOGON, EventID: 5602, Data: “An internal error occurred while accessing the computer’s local or network security database.”

Because the DC rename hadn’t completed successfully, the computer couldn’t actually log into itself to load AD. Very bad for the root of the forest. I wasn’t able to find anything helpful in my searches, so thought I’d let you know the fix:

Name it back to the old name and try again:
Reboot into Safe Mode.
netdom computername localhost /makeprimary:dc04.lwtest.corp
shutdown -r -t 0
Boot normally
netdom computername localhost /makeprimary:dc04.lwtest.corp
netdom computername dc01 /enum
netdom computername dc01 /verify
shutdown -r -t 0
After *that* reboot, make sure, with the verify command, that the old name took, and that you can log in, and just try the rename again.

I couldn’t get the “rename back” to take untill after the attempt in safe mode. Strange, but it’s working great now! Hopefully this will help someone.

 

28/01/2008

DEC 2008 – Chicago

Posted by Robert under Business, Domain Controllers
Leave a Comment 

I have been invited to present at the Directory Experts Conference in Chicago in March, hosted by NetPro Computing, Inc.. I’ll be discussing how we recently integrated dozens of Linux servers into our 300+ server Windows 2000 Native Mode forest. I’m excited, but it’s taking away from the time to update a few things here I have in “unpublished” state.

Of note is a response for T. Colin Dodd regaring his short and sweet post regarding Red Hat Flaws according to Secunia. In short, Mr. Dodd (please correct me if the address is wrong), yes, Red Hat should be proud of what they’ve accomplished, but…

Well, that’s 2 pages of text that’s not yet finished.

 

09/12/2007

Cross-forest trusts and new error codes

Posted by Robert under Domain Controllers, Security | Tags: , , , |
Leave a Comment 

If you are setting up a cross-forest trust with selective authentication (which requires a Windows Server 2003 Native mode level forest and domain), don’t forget to grant the “Allowed to Authenticate” right to the users from the trusted domain to the servers they’ll need access to in your domain. The error messages you’ll get back (replicated here in my test VM domains) don’t really say much helpful.

System Error 317 has occurred. The system cannot find message text for message number 0x*** in the message file for ***.

System Error 317

Further information about adding the “Allowed to Authenticate” right to the trusted users is available at Microsoft TechNet. If you have the opportunity to raise your forest and domain functional levels to take advantage of this, I highly recommend it. But I recommend also (even more strongly) documenting precisely what you set.

 

08/10/2007

How To: Change a Domain Controller IP address: Multi-DCs

Posted by Robert under Domain Controllers, HowTo, Networking
1 Comment 

First, reference back to my first post on Domain Controller IP/Subnet changes. The nice thing about changing IP addresses on DCs in a larger environment, is that it’s actually easier. I have to keep this one quick for now, but will expand based on comments, which you all seem pretty good at leaving (and thank you!). Please, PLEASE refer back to the first post – this one is only an expansion on that one.

  1. Same as before: why are you changing IPs? In larger environments, I do this because of a physical move of just one site. If the networking team doesn’t have the new subnet up and routing, don’t start!
  2. Make sure the new site (if required) is set up in AD. If I’m moving DCs from one physical location to another, I will build a new site, rather than re-using the old one, because the new site often has better connectivity, so the site link costs are changing.
  3. Add the new IP to the DC you’re moving (DC01 for this). Same as before: don’t remove the old one, just add the new.
  4. On DC01, do the following to verify registration worked:
    ipconfig /registerdns
    Wait a few minutes.
    nslookup
    server DC01
    set type=A
    DC01.foobar.local
    foobar.local
    server DC02
    DC01.foobar.local
    foobar.local
    The answers from DC01 and DC02 should be the same, with possibly different orders. The important thing is that the new IP address and the old IP address show up for both queries on both servers.
  5. Shut down DC01, pack it up and move it. (Or just plug it into the new network.)
  6. Boot up, verify that DC01 has network connectivity, and that other systems can see that it has the new IP.
  7. If you haven’t, make the new IP primary (change order in Network settings), make sure the DNS and WINS servers are correct and reachable (Remember that Windows 2003 DNS should point to itself).
  8. Once verifying that AD is replicating across sites properly (up to 15 minutes in my experience), remove the old IP, ipconfig /registerdns, and reboot.
  9. When it comes back up re-verify that AD is still replicating, and you should be set.

I would point out that when doing a change this big to your environment, reviewing your AD replication, DNS forwarding, and WINS topology is a good idea.

 

08/09/2007

Software Discovery: Centrify DirectControl

Posted by Robert under Domain Controllers, Linux
Leave a Comment 

I just finished evaluating an excellent piece of software for Windows / Linux hybrid shops: Centrify Corporation’s DirectControl Suite. This is a fantastically well executed integration suite which allows administrators to bring their GNU/Linux and Unix boxes into the Windows ActiveDirectory domain. This brings centralized control of UID/GID (like NIS), the mutual authentication of Kerberos, and centralized Group Policy control to Linux/Unix.

First off, I’d like to mention that the software installs first on a Windows “console” system. That install has the option of extending the schema, but it is not required (the extensions allows administrators to use the Centrify Profile tab for users and computers without installing the Centrify Console locally).  All required pieces work with the standard out-of-the-box Windows 2003 AD schema.  Although the view extensions are well worth it, if you can get them approved by your AD administrative team.

I installed this on a Debian Etch system and a Red Hat Enterprise Linux 4 box.  They ship RPM and DEB installers, so installation is a snap, and shows up in your package manager.  Restarting the systems was not required, but a few systems may not pick up the new PAM settings without at least a reload (OpenSSH did fine).

One of the best parts of this software, however, is in their updated version of OpenSSH to support Windows Kerberos tickets for authentication of users.  Single-signon to any Linux box from Linux or Windows (customized Putty for the same reason) without having to copy RSA keys across your network every time you build a box.  Now my Oracle admins can log into the 10g databases seamlessly (yes, they support Oracle authenticating through AD as well).

Of course, no solution that integrates into AD would be complete without support for Group Policy.  As a huge user of Group Policy (I have 8 GPOs on my home domain), this is key for me.  The thing that makes it so spectacular, is that they just install new ADM files to your console system.  That’s it – no new trees needed, just new ADM files with settings specific to Linux like “SuDoers entries” and “SSH settings”.  Just like GPO on Windows, they’re applied every 90+-30 minutes, and when you remove the system from the policy, the settings get pulled.  For the Sudoers settings, they are appended to the end of the existing file.  Also, many of your security settings for Windows boxes are read directly by the Centrify systems as well, including password expiration notices, lockout policy handling, etc.

There are so many other little features that show how well thought-out the system is.  The client can be configured to cache logons similar to Windows, so you can control your Linux laptops, and still enable the users to log in when they’re on the road. There are several scripts and other tools to help “suck” the users out of /etc/passwd and NIS into AD, to help keep your UIDs in check if you’re installing the client into existing servers.

And that’s just the operating system.  JBoss, WebSphere, Apache and other applications and middleware can be AD-enabled, and anything that uses PAM is automatically AD-enabled, giving you the ability to set up true single sign-on everywhere in your network, if you so choose.

Needless to say, we purchased it, and I’ll be integrating this into all my deployments from this point forward.

 

Next Page »