• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 394
  • Last Modified:

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
0
snewo
Asked:
snewo
  • 13
  • 9
  • 8
2 Solutions
 
Giuseppe "Pino" De FrancescoSenior Solution ArchitectCommented:
Hiya,

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
0
 
snewoAuthor Commented:

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
0
 
Giuseppe "Pino" De FrancescoSenior Solution ArchitectCommented:
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
0
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

 
Netman66Commented:
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.

0
 
snewoAuthor Commented:

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
0
 
Giuseppe "Pino" De FrancescoSenior Solution ArchitectCommented:
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
0
 
Netman66Commented:
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.



0
 
snewoAuthor Commented:

Net share does not display sysvol when run on the DC.   I do have a c:\windows\SYSVOL\sysvol\mydomain directory but it is empty.



Snewo
0
 
Netman66Commented:
OK.

How many DCs do you have?

0
 
snewoAuthor Commented:

Two



0
 
Giuseppe "Pino" De FrancescoSenior Solution ArchitectCommented:
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
0
 
snewoAuthor Commented:

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
0
 
Giuseppe "Pino" De FrancescoSenior Solution ArchitectCommented:
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.
0
 
Netman66Commented:
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\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID      (where GUID is your domain GUID)
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.



0
 
snewoAuthor Commented:


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
0
 
snewoAuthor Commented:

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
0
 
Netman66Commented:
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

0
 
Giuseppe "Pino" De FrancescoSenior Solution ArchitectCommented:
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


0
 
Giuseppe "Pino" De FrancescoSenior Solution ArchitectCommented:
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
0
 
snewoAuthor Commented:

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



0
 
snewoAuthor Commented:

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
0
 
Netman66Commented:
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.
0
 
snewoAuthor Commented:

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
0
 
Netman66Commented:
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.

0
 
snewoAuthor Commented:

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
0
 
Netman66Commented:
You can use Netdiag, yes.  If it's working you will see the server registered in DNS under _msdcs in multiple containers.

0
 
snewoAuthor Commented:

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
0
 
Giuseppe "Pino" De FrancescoSenior Solution ArchitectCommented:
snewo,

I won't bother you, but in your shoes here is what I'll do (this will preserve your DNS structure but using an intermediate step):

1) Install the Microsoft DNS server on both yours DC
2) Create the zone as Active Directory Integrated
3) In each DNS tab for the network connections on both servers for all NICs (Advanced tab of TCP protocol) ensure that the check box "Register this connection's addresses in DNS" IS Checked
4) Change your DNS config on your servers (dc1 and dc2) so that each server uses itself as primary and the other one as secondary
5) On each server issue these commands (in a CMD window)
       ipconfig /flushdns
       net stop netlogon
       net start netlogon
       ipconfig /registerdns
6) Be sure that both servers are Global Catalog (NTDS Settings in the Active Directory Site and Services). Give the system some time (20 minutes are ok) then run on one of them these commands (in a CMD window)
       REPADMIN /REPLSUM /BYSRC /BYDEST /SORT:DELTA
       DCDIAG.EXE /e

Now you should have no issues (if you still have issues, let us know the issue type, otherwise just continue the next steps)

7) in the zones yourdomain.com and _msdcs.yourdomain.com (in both yours DC) be sure to add the NS record for the Linux machines. To do it (a) add the A record for the linux machine, (b) open the property page for the zone and in the Name Servers tab add the linux machine, then confirm. Do it on BOTH zones.
8) In the property page for the zones (both of them) in the Zone Transfer tab be sure that the check box Allow zone transfer IS checked and the second option is selected (transfer to the servers listed in the Name Servers tab)
9) On the Linux box change the Zone Type of yourdomain.com and _msdcs.yourdomain.com to SECONDARY ZONE, and give the DC1 and DC2 addresses as master servers, than RELOAD the zones from the master.

At this point you should see both zones on the Linux machine exactly the same of the 2003 zones. Now you can revert the situation to the previous one, promoting again yourdomain.com and _msdcs.yourdomain.com to primary zone on Linux, and uninstalling the DNS servers from DC1 and DC2, restoring the previous DNS configuration for the net cards (but leaving the check boxex as are now).

If you issue again:
       REPADMIN /REPLSUM /BYSRC /BYDEST /SORT:DELTA
       DCDIAG.EXE /e
your situation should be normal with no issues at all.

Cheers
Pino
0
 
Netman66Commented:
If you are not able to use an MS DNS solution for the AD and Forward to the *nix DNS then you'll need to get someone that understands Windows DNS to work with your Linux guy.

If you have time, install a test server (use any computer), DCPROMO it and allow the Wizard to install and configure DNS during this process.  When it's complete, you can look at DNS to see exactly what entries are needed.  As you add services to the test server (to match production) you have a perfect lab to see what other records get added to DNS.

0
 
snewoAuthor Commented:

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
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 13
  • 9
  • 8
Tackle projects and never again get stuck behind a technical roadblock.
Join Now