Major problem with ActiveDirectory

Ok, thanks again. Will try your suggestions.

A thought: Is the domain case sensitive?

This is why I wonder: I just tried using Kerberos.app to login to our domain. It worked, but only when I entered our domain in upper case letters. Lower case did not.

This leads me to another question: Is the ability to login via Kerberos independent of having bound the computer to the AD? If not, something really is strange...

-Bo

The domain wants to be in lowercase in the AD Plugin most of the time. Two log files to monitor too would be:

/var/log/krb5kdc/kadmin.log
/var/log/krb5kdc/kdc.log

They might indicate what's failing. I had to do a "su root" in the terminal to access the folder krb5kdc. Good luck...

I am not in a position to rename our domain to a three letter TLD. Our systems people don't like the macs at the best of time, to suggest I go paddling around in their AD. Surely this must be fixed in the near future ? We have one Leopard machine so far on our AD - and it's hella slow. Anyone got any other ideas ? I have tried the suggestions from the other thread for network settings and it didn't have any effect on logon speed etc.

Any more ideas chaps.

I can totally appreciate that, so you'll probably have to wait until they patch it. It really should be fixed, so I imagine if you wait a little while they'll come out with something.

AD admins should not be leaving their domains as .local
it simply is not good practice

I've seen posts regarding .local AD domains and Kerberos issues and I can say I've seen both. I have an .local AD domain and my Macbook Pro is successfully bound to it, but anytime authentication is needed, it's VERY slow. Login is about 1 minute and any authentication is about 30-40 seconds. I've seen this on multiple computers with their AD accounts. I do have one computer that is bound to AD, but Directory Utility says the server is not in the search path (but it is).

The other thing I've noticed, Kerberos authentication is not working for ANYTHING, not just SMB. I have a ticket from our KDC, but I cannot use it for a file server via AFP or SMB. We have ExtremeZIP running on a Windows 2003 cluster and Kerberos will not work. We also have a Windows Print Spool and the 10.5 computers will not automagically connect to it. Logging in with a username and password works, but that's kind of pointless.

kerberos works for comand-line tools, but not GUI apps like Finder or printers.

This was an issue in previous builds, got fixed in the last one, and is now broke again.

Oh, I'd beg to differ there. If you have a domain that you don't want accessible to the outside world you use a suffix like .local or .internal. This is common practice and taught by Mickeysoft themselves. Being an MCSA I'm very aware of the best practices. Furthermore this "practice" works with Windows, Linux, and used to work with OS X. Also, if you have a domain which is not directly connected to the internet (and there are plenty of them, like financial institutions and grocers) you use a faux suffix like local or internal. Apple's XServe is set at .local and you can't change it even if you want. So sorry to say but I think saying that "it simply is not good practice" is bologna. I love Apple but I can't stick up for them on this one, a patch is needed. It may never come, but at least we know of a workaround now.

Brian, I can honestly say loosing the long DNS suffix resolved all the problems you're talking about. Authenticating takes 2 seconds now. Just as it should.

Hi mcornes,Joe,Brian others... I have just struck the same issue, I ended up downloading iservebox from http://www.hanynet.com/iservebox/ and disabling bonjour and bound the macbook.The bind took 30 secs and after the reboot logging into a AD account took all of 1 min from login window. Not sure what it may mess up but I'm up and testing at good speed.Hope this helps.
The test machine is a MacBook 10.5 clean install

Andy

Joe Swenson wrote:
AD admins should not be leaving their domains as .local
it simply is not good practice

Those that don't know, rattle on...
<======>
From Microsoft:
Three practical methods to name the DNS domain are:
• Make the name a private domain name that is used for name resolution on the internal Small Business Server network. This name is usually configured with the first-level domain of .local. At the present time, the .local domain name is not registered on the Internet.
• Make the name a sub-domain of a publicly registered domain name. For example, if the publicly registered domain name is Contoso.com, a sub-domain of Corp.contoso.com can be used.
• Make the name the same as a publicly registered domain name.

*Most Small Business Server customers should use the first method.* The following list describes some of the advantages when you use a separate and private domain name for the local Small Business Server network:
• The management of the local namespace is controlled by the Small Business Server Server. When you use a private FQDN for local DNS name resolution, the DNS server becomes the start of authority for the local domain. This result means that a query to external DNS root servers is not required for local resource name resolution.
• The security may be increased for your DNS server by not enabling zone transfers by means of the zone transfer properties of the forward lookup zone. Because dynamic registration of internal hosts can occur with the DNS server, if you disable the zone transfers from external clients, you can limit the exposure of internal host names to the Internet.
• The natural separation of internal and external networks occurs because of the use of a separate internal namespace. A client query generated from the Internet for www.contoso.local does not return any valid domain information because .local, at the present time, is not a registered domain name. However, by using the Web Publishing rules in Internet Security and Acceleration (ISA) Server, internal Web sites can be hosted externally and viewed by using resolvable domain names. This hosting still requires a registered domain name as well as the appropriate public DNS records that resolve to the external IP address of Small Business Server. Refer to "Configuring Publishing" in ISA Server Help for more information about Web Publishing rules.

The disadvantages of using the sub-domain of a publicly registered domain name or a publicly registered domain name include, but may not be limited to, the following issues:
• Internal clients may be able to resolve resources on the internal domain, however, queries to external resources of the domain are not resolved by the DNS server. For example, if the internal network namespace is configured by using the publicly registered domain name of Contoso.com, only resources that have "A" (Host) records in the forward lookup zone for Contoso.com are available to local clients. This behavior can pose a problem if Contoso.com hosts resources, such as, a web server by means of an external provider or Internet service provider (ISP). Any queries from internal clients to www.contoso.com are resolved as a negative query by the local DNS server because the "A" record for "www" does not exist in the forward lookup zone for Contoso.com. For clients to access external resources, "A" records must be added to the forward lookup zone of the DNS server for those resources.
• The use of a publicly registered sub-domain name can pose the same problems as described for a publicly registered domain name. If at any time, the start of authority for the registered domain (Contoso.com, in this example) adds records for sub-domains, the currently configured private sub-domain may become public.

Name resolution problems that are created by using a publicly registered domain name can be avoided by planning the private namespace around a .local first-level domain so that, in this example, Contoso.com and Contoso.local are both available to internal clients, but Contoso.com is only available to external internet clients.

The use of a separate and private DNS namespace for Small Business Server is consistent with the recommendations in the following Microsoft Knowledge Base article:

254680 ( http://support.microsoft.com/kb/254680/) DNS Namespace Planning
<======>
This is from MSKB 296250

I have NEVER set a domain FQDN to anything other than a .local suffix.

Care to restate your 'expert' advice? Hmmmmm?

If Apple follows Microsoft's 'standard' and Microsoft does what they say they do, it should work.

And I can't even login to my local server but I've been a little busy to spend much time on it. The logging in to Windoze systems has always been a little flaky.

I have had similar problems completing the bind to our Active Directory. In short, I added my root domain (in my case: uiowa.edu) to the "Search Domains" field in the Network pane in the ethernet adapter I'm using.

The long story step by step:
Fresh install.
Installed Keychain/Login update.
Added my computer name listed in Sharing in the correct container in my OU.
Opened 'Directory Utility', typed in my active directory domain name, clicked "Bind" put in my username and password and Computer OU.
It went through steps 1-4 quickly, said it found an existing computer and asked if I wanted to join it, I said yes. It bound properly.
Rebooted and I could not login. It would beach ball for a bit and then the login window would shake it's head 'no'.
I checked various logs in Console.app and particularly found that Kerberos was spouting errors, stating that it "Cannot contact any KDC for requested realm".
I figured it somehow couldn't find it on my network, so I decided to give it some help by adding the "search domain".

It worked!

Hope this works for others. Please let me know your mileage.

Soo..... for me I'd be adding companyname.internal to the Search Domain box. If I set this up as the local administrative user on Network Preferences pane would this network setting carry over to any active directory users that login... since that is the idea of this entire Herculean struggle ?

I have a .local domain on an SBS2003 SP2 server. I have tried everything and followed many suggestions. I downloaded the application iServeBox 1.3 and disabled Bonjour on three systems. All bound to SBS2003 .local domain. Login now take seconds and any validations no longer delay the system a user on OS X 10.5. I am still testing and my systems which are using home folders on the SBS2003 box so I need Active Directory working more than I need Bonjour. It is a great temporary work around until Apple resolves the .local domain issue.

ok, so you're using .internal, now if your DHCP doesn't assign your search domain automatically than you do need to enter that in manually. I'm starting to think from other posts that this is solely relate to ".local" now. I'll ellaborate why in my next posted message.

Message was edited by: p_halcomb

Ok, this makes a lot of sense now. Because Bonjour uses the .local suffix to work.

See this and read the section on "Bonjour and the local link"

http://developer.apple.com/documentation/Cocoa/Conceptual/NetServices/Articles/d omainnames.html

When you setup a new XServe, no matter what you do it wants to be .local and I read that it's for Bonjour to work. So assuming all devices using Bonjour use .local this could be the culprit, a conflict with Bonjour. Tomorrow I'll rename my domain to .internal like the other gentleman has, but setting up DHCP so it automatically assigns the search domain and suffix properly and see what happens. But I suspect it will work beautifully and the problem is only with .local, have a good evening.