We ran into this bit of fun while setting up a NIS domain for testing in the lab today:
rob@rob-kubuntu3:~$ ypcat -d nisdom -h rhel5-64-2 passwd.byname
No such map passwd.byname. Reason: No such map in server's domain
It turns out this was a problem with the /var/yp/securenets file, but I’m still not sure what is wrong. The man page for ypserv shows:
A sample securenets file might look like this:
# allow connections from local host — necessary
host 127.0.0.1
# same as 255.255.255.255 127.0.0.1
#
# allow connections from any host
# on the 131.234.223.0 network
255.255.255.0 131.234.223.0
So we set up our securenets to look like this:
host 127.0.0.1
255.255.255.0 10.10.10.0
And tried to connect to the server:
rob@rob-kubuntu3:~$ ip addr show dev wlan0 |grep "inet "
inet 10.10.10.210/24 brd 10.10.10.255 scope global wlan0
rob@rob-kubuntu3:~$ ypcat -d nisdom -h rhel5-64-2 passwd.byname
No such map passwd.byname. Reason: No such map in server's domain
rob@rob-kubuntu3:~$ ping -c1 rhel5-64-2
PING rhel5-64-2 (10.10.10.213) 56(84) bytes of data.
64 bytes from rhel5-64-2 (10.10.10.213): icmp_req=1 ttl=64 time=0.823 ms
--- rhel5-64-2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.823/0.823/0.823/0.000 ms
Removing the /var/yp/securenets file allowed us access, so it wasn’t firewall or rpc or portmap issues, to the best I can determine. Adding “host 10.10.10.210” also worked and allowed the client access. So what’s wrong with the format / man page?
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: 
. 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.
