Forum Replies Created

Viewing 15 posts - 16 through 30 (of 38 total)
  • Author
    Posts
  • in reply to: Issues with Multiple AD Sites #364684
    Zeheeba
    Participant

    Thats a great idea, and will work on it first thing Monday. Thanks man!!

    Z

    Despite all the frustration this causes, I’m certainly learning a hell of a lot. Smile

    in reply to: Issues with Multiple AD Sites #364677
    Zeheeba
    Participant

    Our situation is an interesting one. We had an existing domain that was basically messed up. After having it picked over it was decided it would be more productive to build a new domain and migrate over to it then try to repair/salvage the disaster that was in place. Since there are about 800 people and a support staff of about 7, the migration is happening over time. So the process goes like this…

    The users account is setup on the new domain, mailbox created etc…
    Their new computer is setup and bound to the network shortly after.
    So yes, the bind is working and the computer account is being produced correctly. But the user account that was created on DC1 might not be on DC3 yet as its in a difference site and only is replicated to every 3 hours.

    Now by the sites and services definitions, no client should ever try to hit DC3 due to its subnet, but for some reason the Macs are, which is causing login failures due to the account name not having been replicated to DC3 yet. If we were persay to always wait 3hours after creating the users account we wouldn’t have the authentication problem because the account would be on DC3. But the real problem is that the Macs are looking to DC3 at all, when they shouldnt be.

    Life can never just be easy ya know? : )

    in reply to: Issues with Multiple AD Sites #364661
    Zeheeba
    Participant

    [QUOTE BY= MacTroll] Is dc3 in the site for the clients? [/QUOTE]
    No, DC3 is in a second site which is linked to a subnet that the client doesn’t lie in.

    [QUOTE]The plugin should contact all of the site and test them to see if they actually are there.[/QUOTE]
    This explains why our TCP Dumps are showing the client talking to all 3 domain controllers on Bind. After I viewed the dumps I was hoping this was a normal thing, this clarifies it, thanks.

    [QUOTE]Also, I’d be curious as to what the _ldap._tcp. SRV records are returning, since those could be pointing to the third site also.[/QUOTE]
    DNS INFO (I can’t get tabs so show up so its a bit crushed):

    AD main portion:
    “_ldap._tcp.dc._msdcs SRV 0 1 389 dc01
    SRV 0 2 389 dc02
    SRV 0 3 389 dc03″

    AD Sites protocol Portion:
    “$ORIGIN _tcp.Co-Main._sites.company.com.
    _ldap SRV 0 100 389 dc01.company.com.
    SRV 0 100 389 dc02.company.com.
    $ORIGIN _tcp.DR._sites.company.com.
    _ldap SRV 0 100 389 dc03.company.com.”

    This shows the 2 sites, Co-Main, and DR

    AD TCP Portion:
    “_ldap SRV 0 100 389 dc01.company.com.
    SRV 0 100 389 dc02.company.com.
    SRV 0 100 389 dc03.company.com.”

    AD MSDCS Portion:
    “$ORIGIN _tcp.Co-Main._sites.dc._msdcs.company.com.
    _ldap SRV 0 100 389 dc01.company.com.
    SRV 0 100 389 dc02.company.com.
    $ORIGIN _sites.dc._msdcs.company.com.
    $ORIGIN _tcp.DR._sites.dc._msdcs.company.com.
    _ldap SRV 0 100 389 dc03.company.com.”

    [QUOTE]Or… you can just cheat and pre-create the machine account and let it replicate out. Then bind after that.[/QUOTE]
    The problem isn’t th at the machine account isn’t being created on all 3 DC’s, because it is on bind. The problem is that the persons account is created manually right before the bind, and that info doesn’t hit DC3 for until the next 3 hour replication schedule push occurs. We could create the account on DC3 as well, but who wants to do that? ; )

    [QUOTE BY= chrisjasper]Cant think of a way to ensure that it fnds the other local DC first though as I believe it queries DNS and takes the first apllicable record it receives so if the 3rd DC is named in a way as to place it higher in the list of entries it would probably get picked up first.[/QUOTE]
    You just hit the root of the problem. AD is supposed to be able to tell that the client is sitting in a subnet in site Co.Main and send it to the domain controllers for that Site/Subnet first, which are DC1 and DC2. I still think your idea of setting a preferred DC might be the correct workaround for this issue.

    Thanks again guys, as always, any help is appreciated.

    Regards,
    Z

    in reply to: Issues with Multiple AD Sites #364652
    Zeheeba
    Participant

    Thanks for the reply Chris. If I understand correctly, this would solve the problem by telling the computer to always use on DC. My only concern with this is that it would disable any mac bound using this setting if the DC should go down, as it wouldn’t seek out any others. Although I could be wrong on this.

    If you can specify a DC and have the machind query for the others if the primary is not available, than this would be at least a workaround for when the stated primary is up and operational.

    Good Idea. Its not a real fix per say, but definitly a work around. : )

    in reply to: Issues with Multiple AD Sites #364650
    Zeheeba
    Participant

    Hello again,

    We have continued to have problems in our environment regarding OSX machines authneticating to a DC in a different AD site, and having authentication fail as Active Directory only replicates to this 3rd DC every 3 hours, instead of 5 minutes.

    We have proof of this via TCP dumps being run before the initial Bind through the login to create a network user. When the osx machine is bound to the domain it actually contacts every domain contoller ( in our case dc1, dc2, and dc3), not just one, possible to create the machine account on all dcs. The problem is that the user account that is created manually on a domain controller in the same site as the client (dc1 or dc2) is not replicated to the DC in the different site (dc3) until the next 3 hour replication.

    For some reason certain clients are hellbent on authenticating users against this 3rd domain controller, even though AD specifically says that the dc’s for the clients subnets are dc1 and dc2. This at least to me is showing that for authentication the AD plugin is not respecting sites and services.

    A guess as to the source of this problem…
    – Since the bind is contacting every domain controller, is it possible its putting the last DC it spoke to in a prefernce file as preferred domain controller for a certain period of time? This would explain the problems we are seeing as holding onto this 3rd DC instead of querying ad everytime as it should.

    Any help would be appreciated. This is going to be a real problem for us. Thanks!

    Regards,
    Z

    in reply to: Issues with Multiple AD Sites #364306
    Zeheeba
    Participant

    Thanks man, I’ll check it out.

    Regards,
    Z

    in reply to: 10.4 AD Bind #362725
    Zeheeba
    Participant

    Duh…

    For anyone else who is having a brain leak, just do a man on dscl.

    : )

    Z

    in reply to: 10.4 AD Bind #362721
    Zeheeba
    Participant

    Hello There,

    Do you happen to remember where you found the list of all the different variables used for the AD plugin? I need the ones you mentioned in your original post, but need many others from the other config tabs.

    Any help would be appreciated.

    Regards,
    Z

    in reply to: Server Problem Notification – Intrusion #362608
    Zeheeba
    Participant

    Howdy. Certain first generation Xserves had cases that bent over time which I was told are called “Smiling Xserve’s”. I was told they had a recall on these at one point. Anyway, some of ours are smiling and others are not, but I have had this email notification problem from both.

    If you pull your Xserve out of its chassis only about an inch, you will see a small metal pin sticking up around the middle of the Xserve along the front display panel. This pin or lever is what detects weather the Xserve has been opened.

    I resulted to taping it down securely. I have not had a problem with the email since. Now granted, our Xserves are in a secure data center, so its not as big a deal. If it was out in the middle of nowhere, I would think differently.

    Hope this helps…

    Regards,
    Z

    in reply to: Power outage then users can’t log in #362422
    Zeheeba
    Participant

    Is it possible your client machines are setup to mount a share on boot and are not able to find it? I’m not sure if it still happens in 10.4, but in the Mac past, this could be a problem.

    The “Mount server upon Startup” box was a nightmare. Just a thought.

    Regards,
    Z

    in reply to: Reverse DNS lookups failing #362353
    Zeheeba
    Participant

    That would do it. Big Grin
    Have a great week.

    Regards,
    Z

    in reply to: Reverse DNS lookups failing #362351
    Zeheeba
    Participant

    Hey There…

    As I understand it, PTR records are reverse records. So if PTR records are working then you should be fine. What DNS server do you have specified for the second Nic?

    Can you post the full dumps or post just simple nslookups? That may shed some light..

    Thanks!

    Z

    in reply to: Active Directory, SMB, and PCs #362297
    Zeheeba
    Participant

    Thats great man, glad it worked! In 10.4 all of this was taken care of on the fly, so all you have to do is setup the Directory Services, and join the Kerb domain. After that, smb is automatically a domain member.

    It only spent a couple days messing around with settings to figure out this process only to have Apple fix it. LOL. Better for it to be fixed, its much easier.

    Gratz,

    Z

    in reply to: Active Directory, SMB, and PCs #362295
    Zeheeba
    Participant

    **EDIT**

    Okay, I just ran through the process on another of my servers that I needed to set up anyway. Here are the exact steps.

    1.) Setup Directory access so you are bound to the AD domain. Make sure the AD domain is showing up in your authentication path.

    2.) Open up Server admin. Go to the “OpenDirectory” bubble. Click on the Settings tab. Click on the “Join Kerberos” Button. You will need to authenticate as a user on AD that has permissions to do this. There is no real message that saying this succeceded. I think it will tell you if it fails due to permissions and such.

    3.) Click on the Windows Bubble in ServerAdmin. Stop SMB Services.
    vi into your /etc/smb.conf. Make the following changes:

    security = domain
    WORKGROUP = “your domain name” IN our case its ZREALM.ORG and I needed to use just ZREALM without the org”
    use spnego = yes

    Close and save conf file.

    4.) Go back into ServerAdmin and click on the Windows bubble. Before you start service click on the Settings tab. Select “Domain Member” from the drop down menu. Now keep in mind that a bunch of ” I can’t save this info” boxs will appear, click to close them and forget about them. Fill in the Domain box with the same info you entered in the conf file, in my case ZREALM. Once that data is complete, click save. It will then ask you to authenticate again. Enter the username and password and click okay.

    5.) Now start up Windows services. Click refresh on the top bar and you should see that “Domain Member” sticks. If all went correctly, you should be all set up for domain kerb authentication.

    My fingers are crossed for ya.

    Regards,

    Z

    in reply to: Active Directory, SMB, and PCs #362291
    Zeheeba
    Participant

    Hey There,

    I have a similar setup with a 10.3.9 Xserve. The differences I see between your conf file and mine are the following:

    security = domain
    auth methods = guest ntdomain opendirectory

    If you open up Server admin, and view the settings for Windows, does it say that you are a “Domain member”? The mac can be bound to AD via the plugin and have auth working fine, but if the SMB portion isn’t listed as a domain member, I believe you will still have problems logging in from PC’s.

    Good Luck.

    Z

Viewing 15 posts - 16 through 30 (of 38 total)