[anodyne]

It is interesting. I can still reliably bind 10.5.2 machines in our domain with dsconfigad defaults (i.e. allow). For 10.5.3 fresh installs/binds, I have found it necessary to disable both packet signing and encryption to have any success with the initial bind. We’re still working through this, but definitely can reproduce this experience in our domain since the 10.5.3 point update. Thanks.

Curtis

[anodyne]

Since I posted in this thread, I thought I should provide a brief update relating to the 10.5.3 update and subsequent binding issue. I have had assistance in determining that disabling packet signing and encryption (dsconfigad -) prior to binding resolves this issue. Evidently some changes were made in 10.5.3 around the area of packet signing and/or encryption. Were still at the early stages regarding this discovery so I don’t have much more information. That said, this will allow me to test the 10.5.3 server update in relation to the AD/AFP issue we have been experiencing with 10.5.2 server. Good times.

Curtis

[anodyne]

I’m with a large K12 school district. We have been trying to maintain momentum here in regards to AD integration (all users in Active Directory). Unfortunately, w/in our organization, Apple’s AD support/reliability has been found lacking (overall lack of continuity between releases/updates). The most recent example is the Leopard release. We weren’t able to bind to AD in our (large) domain until 10.5.2 came out. Now with the 10.5.3 release we are unable to bind again. I have found that I can take a 10.5.2 AD bound machine and upgrade it to 10.5.3 and it maintains it’s bound state. Unfortunately, if I choose/need to unbind, I am unable to rebind under 10.5.3 (this applies to client and server). The issues we have seen maintaining Active Directory integration w/in our organization has not made us particularly optimistic regarding binding many more of our ~10,000 Mac clients.

I have also been experiencing issues with 10.5.2 server relating to AFP and AD accounts. AFP will eventually become dysfunctional with AD accounts (local/OD accounts continue to work). SMB continues to work during this time with AD accounts. I have found unbinding/rebinding to more often than not be the (temporary) solution to this issue. Again, doesn’t bode well for further AD integration of servers. I’ve had a case open for ~1 month on this issue w/out any progress.

We are currently rolling out an Oracle Identity Management solution. I had hoped to continue using the magic/golden triangle approach (we had great success in the 10.3.x days, and OK success under 10.4 with the exception of AFP reliability/performance issues). Now I’m thinking I should examine the OpenLDAP/OD route with the use of a connector given the issues with Mac’s and AD here. We will also be looking at retreating from our continued XServe/OSXS purchases and taking another look at the Group Logic ExtremeZ-IP solution, consolidating on the Windows backend.

Best of luck/sucess in your chosen direction!

Curtis

[anodyne]

Sorry to hear that didn’t help with the issue. We did that at one of our sites to resolve the boot issue. One other thing that I can think of …. the “Add DHCP-supplied LDAP servers to automatic search policies” should not be checked if you are not handing out that info. via DHCP. This shouldn’t be checked by default, but I came accross a machine that had that set and was taking a great deal of time to boot. Best of luck and please post solution when things are corrected. Thanks much!

[anodyne]

I’ll just mention that that a server I upgraded last evening took ~5 attemps (including a need to force quit Directory Access app). However, this was a fully updated 10.4.7 Universal …. perhaps something with a security update? I haven’t heard anything from our techs yet on any client side bind issues. Thanks.

Curtis

[anodyne]

Try giving this a whirl … System Preferences > Network > Network Port Configurations; put your primary port config at the top (disable remaining ports if possible, prioritize at the very least). If wireless, I would establish/join your access point, then set AirPort configuration to “join preferred” and click your heels 3x 🙂

The above resolved this particular issue with Intel iMacs we recently received (also bound to AD/OD). Unfortunately, we are currently experiencing others probs ranging from anemic AFP services (have done some tuneage, now just pray for a 10.4.8 update than includes 10.4.7 Uni changes), crashing apps (using Network Homes), and now less than consistent MCX application dabbling with Portable Homes. Good times! Why do I long for the 10.3.x days (Thanks Michael!)?

Curtis

[anodyne]

Thanks for the reply. Yeah, I wasn’t seeing any options using dsconfigldap, I’ll look into defaults usage …

[anodyne]

I’m not finding the evidence to back me up at the moment, but I’m fairly sure this issue was dealt with in a Tiger update (10.4.3?). I recall it being explicitly listed as a fix … now I can’t seem to locate any mention of it. At any rate, the issue has been resolved for our organization through an update.

[anodyne]

A little more regarding our situation:

As mentioned earlier, our users are in Active Directory. Our XServes are bound to AD, but our clients are not at this time. Servers running 10.4.3 and most clients are as well. We are hoping to bind all clients, but at this time it doesn’t appear that we have the support structure in place to manage all clients (numerous sites) successfully in an AD/Open Directory Master environment. Someday, but I digress …

When we initially observed this “Disabled/Asleep” AFP problem, we made some changes to the Profile/Home Folder path which seemed helpful (i.e. move toward using FQDN). This helped, but did not totally remove the issue. Given that we don’t have (most) clients currently bound to AD, we have since chosen to completely remove the home folder path for those users. Students use the “Connect to Server” method from a local user account, and specify their AD credentials to mount share/navigate to their home. What has seemed to help was changing the Authentication mode from “Any” to “Standard” … I’m not fond of this as it breaks AFP SSO. Changing to Kerberos doesn’t work at all .. I imagine that it’s expecting to be the KDC, not AD. I played around a little with Idle users w/out success. I will also note that this issue doesn’t plague all sites equally … some barely/ever see the issue while others are highly impacted.

Also, when we do observe this issue, a “top -o cpu” will reveal the AFP process at 90%/climbing. Sometimes trying to stop the AFP process via Server Admin will hang the machine (pingable, but not SSH/etc) and a physical reboot will be needed.

BTW, does anyone know what “AFP_Check” (or something very similar) is doing? I just noticed it as a running process last evening …..

[anodyne]

We are seeing the same issue here. Active Directory bound servers w/ user home directories. I was hoping the 10.4.3 upgrade would be helpful .. unfortunately nothing has changed since upgrading. The problem can hit multiple times in the day. Sometimes disconnecting the “Disabled/Asleep” connections can get things going again, more often I need to stop/start service or reboot server to get things going. Not good at all …

[Author]

Posts