snewo
asked on
AD User Permissions Problem - Very Strange
When I follow the following steps, I run into a permissions problem. Any ideas?
For this example: Domain = mydomain
Step 1: Log into a DC (we'll call server1) and create a new AD user: User logon name: newuser PW: password Member of Domain Users.
Step 2: Log into a different server in the domain (we'll call that server2)
Step 3: While on server2, I try to map a network drive to a share on server1.
- The share called sharename$ has permissions of Everyone with full control.
- Security tab has users given read&exe; List Contents; Read;
- I use this for folder when mapping: \\server1\sharename$
- I choose connect using a different username and use the following: Username: mydomain\newuser Password: password
When I select ok to make this network drive, I get another login window again. It tells me my password is bad. If I wait for a while, everything seems to work eventually. I suspected a password synchronization issue, but I reset the password on all domain controllers to the same value and tried again - still got the same error. If I waited a little while again - poof it works. Any ideas?
Help!
Snewo
ASKER
During step 2 I'm logged in as admin not as the new user. I should have mentioned that.
w2k format does the same thing.
Snewo
Obviously the w2k format does the same, but I experienced that sometime (without reasons) the w2k3 format is the only accepted. I have (in a customer site) on this behaviour a Microsoft SRQ open (since 3 months) and still investigating, meanwhile they can not use the w2k format... don't ask why... :) So, before getting crazy, just try the w2k3 format and see what happen, may be you are in the same situation.
Let me know.
Cheers
Pino
Let me know.
Cheers
Pino
It's all about replication. Server2 does not have the account information yet (if it's a DC).
Convergence is the state of equilization - meaning, until full sync (convergence) the account information is not available. Depending on your topology and/or traffic, replication may be slow.
From Server2 you should run NETDIAG and see if there are issues that are not apparent on the surface.
Convergence is the state of equilization - meaning, until full sync (convergence) the account information is not available. Depending on your topology and/or traffic, replication may be slow.
From Server2 you should run NETDIAG and see if there are issues that are not apparent on the surface.
ASKER
You misunderstood me Pino. I meant that I tried, but the w2k format does the same thing.
Netman, I ran netdiag. There are two items that came up with issues. The 2nd one smells like the cause of the issue I'm having.
1 - DNS test. Both of my DNS servers gave me warnings stating that the DC is not registered correctly. Since I'm not using Windows DNS servers, I'm guessing this is to be expected. Is that a problem? We do not want to change out DNS infrastructure.
2 - Domain membership test Failed. "hs system volume has not completely replicated to the local machines. This machine is not working properly as a DC."
Since I'd like to fix this issue, I did a little research. Is this: http://support.microsoft.com/?id=315457 the only way to fix the problem? How drastic is this? Can this hurt my other domain controller too? I'm not looking to bring down the entire domain.
Snewo
Ops, a DC have to run a DNS server, each of the DC have to. This is not optional... All tries to avoid this generate problems in such way.
Pino
Pino
Each DC does NOT need to run DNS. As long as one DNS server is reachable you're fine. Pino - if you are not 100% sure of what you advise people then don't advise people. We're dealing with Production networks here, bad advice is the last thing people need.
Now....
Please type NET SHARE on this server at the CMD prompt. Let me know if SYSVOL shows up in the results.
Now....
Please type NET SHARE on this server at the CMD prompt. Let me know if SYSVOL shows up in the results.
ASKER
Net share does not display sysvol when run on the DC. I do have a c:\windows\SYSVOL\sysvol\m
Snewo
OK.
How many DCs do you have?
How many DCs do you have?
ASKER
Two
Netman66:
I'm absolutely sure about my consultancy buddy: the common scenario is 2 DC, so if YOU suggest only one DNS AD Integrated, if that goes down, the other DC (without its own DNS as you suggest) is not able to supply the correct service nor AD capable to work correctly.
If YOU want expose people to this kind of risk, you're free, but please, at least, avoid to tell others to think like you. I do this job since 26 years: I'm strictly sure about what I write.
The real world is not a blog or a website where show how many books you have read or how you are good to search the Internet... the real world is made by experienced people dealing with real scenarios. Just keep a VERY low profile when you do not know whom is writing kiddo.
Pino
I'm absolutely sure about my consultancy buddy: the common scenario is 2 DC, so if YOU suggest only one DNS AD Integrated, if that goes down, the other DC (without its own DNS as you suggest) is not able to supply the correct service nor AD capable to work correctly.
If YOU want expose people to this kind of risk, you're free, but please, at least, avoid to tell others to think like you. I do this job since 26 years: I'm strictly sure about what I write.
The real world is not a blog or a website where show how many books you have read or how you are good to search the Internet... the real world is made by experienced people dealing with real scenarios. Just keep a VERY low profile when you do not know whom is writing kiddo.
Pino
ASKER
I'm using Linux DNS not Microsoft. I suspect that is where the disconnect is Pino. Either way I appreciate both of you trying to help me with this.
Snewo
FYI: http://support.microsoft.com/kb/291382/en-us
Extract:
Question: What are the common mistakes that are made when administrators set up DNS on network that contains a single Windows 2000 or Windows Server 2003 domain controller?
Answer: The most common mistakes are:
• The domain controller is not pointing to itself for DNS resolution on all network interfaces.
• The "." zone exists under forward lookup zones in DNS.
• Other computers on the local area network (LAN) do not point to the Windows 2000 or Windows Server 2003 DNS server for DNS.
Question: Why do I have to point my domain controller to itself for DNS?
Answer: The Netlogon service on the domain controller registers a number of records in DNS that enable other domain controllers and computers to find Active Directory-related information. If the domain controller is pointing to the Internet service provider's (ISP) DNS server, Netlogon does not register the correct records for Active Directory, and errors are generated in Event Viewer. In Windows Server 2003, the recommended DNS configuration is to configure the DNS client settings on all DNS servers to use themselves as their own primary DNS server, and to use a different domain controller in the same domain as their alternative DNS server, preferably another domain controller in the same site. This process also works around the DNS "Island" problem in Windows 2000. You must always configure the DNS client settings on each domain controller's network interface to use the alternative DNS server addresses in addition to the primary DNS server address.
Extract:
Question: What are the common mistakes that are made when administrators set up DNS on network that contains a single Windows 2000 or Windows Server 2003 domain controller?
Answer: The most common mistakes are:
• The domain controller is not pointing to itself for DNS resolution on all network interfaces.
• The "." zone exists under forward lookup zones in DNS.
• Other computers on the local area network (LAN) do not point to the Windows 2000 or Windows Server 2003 DNS server for DNS.
Question: Why do I have to point my domain controller to itself for DNS?
Answer: The Netlogon service on the domain controller registers a number of records in DNS that enable other domain controllers and computers to find Active Directory-related information. If the domain controller is pointing to the Internet service provider's (ISP) DNS server, Netlogon does not register the correct records for Active Directory, and errors are generated in Event Viewer. In Windows Server 2003, the recommended DNS configuration is to configure the DNS client settings on all DNS servers to use themselves as their own primary DNS server, and to use a different domain controller in the same domain as their alternative DNS server, preferably another domain controller in the same site. This process also works around the DNS "Island" problem in Windows 2000. You must always configure the DNS client settings on each domain controller's network interface to use the alternative DNS server addresses in addition to the primary DNS server address.
Right...
You're wrong and I stick to that. You stated you HAD to have DNS on a DC. Wrong. In this case the user has a non-MS DNS solution in place already. As long as it supports DDNS and SRV records then it's fine. As far as redundancy goes you can run any number of DNS servers and they don't HAVE to be on the DC as you so adamently stated. I've been in this industry as long as you have so you can quit throwing stones anytime now.
Now back to the question.
Stop FRS server on both DCs. Set startup type to manual (it's temporary).
On the primary DC (the one that has the good SYSVOL) open up Regedit and go here:
HKEY_LOCAL_MACHINE\SYSTEM\
In the Burflags key, set the value to D4. Close Regedit.
On the bad DC, go to the same key as above only make the value D2.
Restart FRS on the good DC (the one you changed to D4) and set the startup type to Automatic.
Wait a few minutes.
Restart FRS on the bad DC (the one you changed to D2) and set the startup type to Automatic.
Wait.
SYSVOL should rebuild itself on the bad server from the good server. When it is successful, SYSVOL with share out automatically.
You should be good to go.
One note. Whatever DNS you are using, be sure the SRV records, A and PTR records exist for both servers properly.
You're wrong and I stick to that. You stated you HAD to have DNS on a DC. Wrong. In this case the user has a non-MS DNS solution in place already. As long as it supports DDNS and SRV records then it's fine. As far as redundancy goes you can run any number of DNS servers and they don't HAVE to be on the DC as you so adamently stated. I've been in this industry as long as you have so you can quit throwing stones anytime now.
Now back to the question.
Stop FRS server on both DCs. Set startup type to manual (it's temporary).
On the primary DC (the one that has the good SYSVOL) open up Regedit and go here:
HKEY_LOCAL_MACHINE\SYSTEM\
In the Burflags key, set the value to D4. Close Regedit.
On the bad DC, go to the same key as above only make the value D2.
Restart FRS on the good DC (the one you changed to D4) and set the startup type to Automatic.
Wait a few minutes.
Restart FRS on the bad DC (the one you changed to D2) and set the startup type to Automatic.
Wait.
SYSVOL should rebuild itself on the bad server from the good server. When it is successful, SYSVOL with share out automatically.
You should be good to go.
One note. Whatever DNS you are using, be sure the SRV records, A and PTR records exist for both servers properly.
ASKER
Ok, I'm in the process of doing what you suggested. Our Linux guy says we do not have PTR records or SRV records. We only have A records. He says all DNS entries were set-up per the documentation and recommendation of the MCSE we had in to do our AD installation. I guess something was missed? What resources should be in the SRV and PTR records?
It feels like we're almost there.
Snewo
ASKER
Correction, upon further review I think we DID have the SRV records. We were only missing the PTR records from what I can tell. I'm going to get those added.
As for the results of the above: No sysvol share yet....
Snewo
Your DNS must support SRV records at the bare minimum for AD to work. DDNS is not required, however you'll have a huge headache trying to add all the proper records by hand if your DNS doesn't support this.
Make sure there is nothing blocking proper communication between servers.
In MS DNS, all the SRV records are located under _msdcs.domain.com (or inside domain.com in a folder named _msdcs for Windows 2000). I'm not sure what how non-MS DNS represents SRV records, but they must be compliant in order for any domain query for SRV records to succeed. It could be (and this is a guess) that the SRV records are not complete or setup properly. Please note that I am only making a guess here.
As long as your Linux guys know how to setup DNS for AD, then you should be okay.
You can test SRV records by pinging the GUID of the domain (ping GUID) or the GUID of the server (ping GUID.domain.com) and you should get a reply.
This might help: http://go.microsoft.com/fwlink/?LinkId=30720
And this page pretty much spells it out and contains most of the things you may need to know - same applies to 2003 AD.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsguide/part1/adogd10.mspx
Make sure there is nothing blocking proper communication between servers.
In MS DNS, all the SRV records are located under _msdcs.domain.com (or inside domain.com in a folder named _msdcs for Windows 2000). I'm not sure what how non-MS DNS represents SRV records, but they must be compliant in order for any domain query for SRV records to succeed. It could be (and this is a guess) that the SRV records are not complete or setup properly. Please note that I am only making a guess here.
As long as your Linux guys know how to setup DNS for AD, then you should be okay.
You can test SRV records by pinging the GUID of the domain (ping GUID) or the GUID of the server (ping GUID.domain.com) and you should get a reply.
This might help: http://go.microsoft.com/fwlink/?LinkId=30720
And this page pretty much spells it out and contains most of the things you may need to know - same applies to 2003 AD.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsguide/part1/adogd10.mspx
Hiya,
just to avoid more invasive operations, let us have some good (and basic) diagnostic test done. From a CMD shell on a w2k3 server issue these commands:
REPADMIN /REPLSUM /BYSRC /BYDEST /SORT:DELTA
then
DCDIAG.EXE /e
Let see if all the tests passes or we find any failure. Let us know.
Cheers
Pino
just to avoid more invasive operations, let us have some good (and basic) diagnostic test done. From a CMD shell on a w2k3 server issue these commands:
REPADMIN /REPLSUM /BYSRC /BYDEST /SORT:DELTA
then
DCDIAG.EXE /e
Let see if all the tests passes or we find any failure. Let us know.
Cheers
Pino
A note about the Linux box: If your BIND version is not greater or equal to the 8.2, Active directory will not be able to work 100%, that's for sure.
Cheers
Pino
Cheers
Pino
ASKER
Here is the results of the repadmin:
-----------
Replication Summary Start Time: 2006-03-22 17:12:53
Beginning data collection for replication summary, this may take awhile:
.....
Source DC largest delta fails/total %% error
WORKINGDC 27m:19s 0 / 3 0
Destination DC largest delta fails/total %% error
DCWITHERRORS 27m:19s 0 / 3 0
Assertion
-------
The DCDIAG gives me the following issues:
- Can't ping the GUID, so Connectivity test failed.
- kccevent test failed. EventID: 0x80000785
- Schema test failed for CrossRefValidation. LDAP Error 0x3a
Yesterday was hectic so I'll see I plan to see if we have everything set-up per Netman66's last link.
Snewo
ASKER
OK, so looking at the Linux DNS entries, I suspect things are not correct. Since the entires on this DNS server (We're using Bind 9.2.something fyi) were dynamically created, how do I get the working DC to dynamically create this information again? Hopefully this will solve the issue. Of course, I'd like to limit any downtime needed to do this.
Snewo
On the working DC (actually everything inside your LAN should point only there), make sure you ONLY point to the Bind DNS installation and that on the Properties of TCP/IP> Advanced button > DNS tab that Register in DNS is checked off. On the Bind server, make sure that the domain zone for your AD allows Dynamic Updates (not sure where this is found).
Restart the Netlogon Service on this DC and the records should be created if the Bind server is setup properly.
Once the SRV records are created, replication should start properly as the other server can now locate the primary DC by service record.
Keep us posted.
Restart the Netlogon Service on this DC and the records should be created if the Bind server is setup properly.
Once the SRV records are created, replication should start properly as the other server can now locate the primary DC by service record.
Keep us posted.
ASKER
Do I need to leave the "register in DNS" checked off, or can I turn it back on once I've completed the above?
How about my second DNS, can I add it back after I've finished?
Snewo
By saying "leave it checked off", I meant make sure the checkmark is there - sorry about the confusing sentence.
Yes, it will remain "checked" always.
You can add the second DNS server as a secondary as long as the records get created on the first. If they aren't being created we have to find out the root cause of this.
Yes, it will remain "checked" always.
You can add the second DNS server as a secondary as long as the records get created on the first. If they aren't being created we have to find out the root cause of this.
ASKER
Doesn't seem to have fixed the problem. I'm going to do it again since it's simple enough. I don't remember if I removed the backup DNS when I did it a second time with the box checked off.
Are there logs on the working DC that I can use to verify that it's doing what we think it's doing? The way I'm testing the non-working DC is to run netdiag on it and look for the errors. I assume that'll catch it.
Snewo
You can use Netdiag, yes. If it's working you will see the server registered in DNS under _msdcs in multiple containers.
ASKER
It still does not appear to be working. I'm getting some msdcs entries in our DNS, but there's obviously some disconnect here.
Do you have any other ideas for me to try? If not I'm wondering if it's beyond forum help. This may be time to bring in the MCSE again and put him in a room with the Linux guy and let them figure it out.
Snewo
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I plan on bringing in the guy who set-up our network to work with our Linux guy on this. I appreciate everyone's help. I'm giving points out, not because we solved the problem, but because the steps you gave me helped me learn some things.
Snewo
I miss some... why being logged as newuser you choose to map using a different user and give the same one? anyway, try the current w2k3 format for the user name: newuser@mydomain. Let me know.
Cheers
Pino