[trice]

Correct, they are not getting tickets automatically on login. Haven’t tried kinit from the command line, but have used the Kerberos GUI app on the clients and they can get tickets that way. In the Authentication Authority and the dsAttrTypeNative:AuthAuthority fields under the inspector window in WGM the old realm name is listed under the kerberos values. If I edit those fields to the new realm name it doesn’t change anything. If I add a brand new user, then all is well. They have the correct info listed in WGM and can connect to Kerberized shares without being prompted for a password.

tom

[trice]

If i go into the kerberos app on the client it shows not tickets have been requested. If i request a ticket from the kerberos realm I can then connect to the afp shares without being presented with a logon box. – If i add a completely new user then they get the tickets fine. So it seems something got screwed up in the migration of server names. I followed the instructions here http://docs.info.apple.com/article.html?artnum=107702 which did in fact remove the duplicate realm names that existed, but current users are still not granted tickets upon logging in.
Looking at the users in the inspector window in WGM, it shows that they do indeed list kerberos as an authentication authority, but it has the old realm listed. Any ideas on how to fix this for everyone?

Any thoughts on how this can easily be fixed without forcing 5000 users to reset their passwords after i reimport them?

tom

[trice]

Thanks Joel, everyone, for giving me some more info to make our windows admin, whose been largely uninterested/unresponsive, take a closer look at this.

tom

[trice]

one more thing – as i mentioned previously the DNS is active directory integrated so the DNS information is stored in the active directory database NOT in zone files – and the windows admin has not be so forthcoming about letting me poke around in that database to extract the info i need – another reason why more infor hasn’t been readily forthcoming

[trice]

Yes – I’m assuming it is related to the Windows 2003 GUI, which is where the DNS is currently running. I can’t find anything specifcially wrong in any of the 2003 logs or files. If you would like to see the specific contents of any Windows 2003 DNS file the please let me know what you you like to see and which files. Again this is a Windows 2003 DNS server running Windows 2003 DNS not OS X DNS or any other version of BIND. And I never said I couldn’t add A records, the A record adds itself fine each and every time I add it, but rather that the A record I add keeps changing.

[trice]

Except that this machine is not 10.5 its a 10.4.11 server and its not bound to AD. Our DNS is however Active Directory integrated.

tom

[trice]

Ok let me see if i can explain it more clearly – bear with me this problem doesn’t make a whole lot of sense to me either and this has yet to be documented anywhere as far as I can tell

We have a domain in our Forward lookup zone on our Windows 2003 DNS Server. Lets call this domain EXAMPLE.COM. So going into our DNS Server you would open the forward lookup zones and see EXAMPLE.COM. There is also a corresponding reverse lookup zone for this domain. In EXAMPLE.COM I can add A records, MX records, etc etc. Including the A record for our open directory master. This record now reads opendirectorymaster.example.com A few seconds after adding that A record it changes to a subzone within EXAMPLE.COM

So initially we have

 Forward Look Up Zones
&nbsp&nbsp&nbsp&nbsp&nbsp EXAMPLE.COM&nbsp (A Record) opendirecotrymaster

then it changes to

 Forward Look Up Zones
&nbsp&nbsp&nbsp&nbsp&nbsp EXAMPLE.COM
&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp OPENDIRECTORYMASTER

So now if i wanted to i could actually add an A record within the opendirectorymaster zone to someting like server.opendirectorymaster.example.com. Clearly not what I want to have happen.

Does that clear it up?

weird right?

[trice]

Exactly, I don’t understand either and everything is working, well mostly. The problem is not with DNS resolutions for the most part, if you read the original post again you will see the problem is with the DNS record changing types. The A record for the server changes to a subdomain within our current DNS structure. For example, we have a domain called domain.com We add a A record for this server so we have server.domain.com That A record promotes itself to a subdomain within our domain. So now we have server.domain.com as a subdomain within our domain to which (if we wanted) A records, reverse records, etc could be added. Not a good thing as far as pure DNS resolution since sometimes something resolve to server.server.domain.com.

tom

[trice]

lookupd -q host -a name [i]FQDN of my server[/i]

interface: 5
ip_address: [i]Returns Correct IP[/i]
name: [i]Returns correct FQDN[/i]

lookupd -q host -a ip_address [i]IP of My Server[/i]

ip_address: [i]Correct IP[/i]
name: [i]Correct Reverse Mapping[/i]
ptrdname: [i]Returns correct FQDN[/i]

[trice]

Both the OD Master and the Clients are getting their DNS from the Windows Box. So even if I were to start DNS on the master the clients would still be affected.
Everything still works for the most part, but its just some things that are getting thrown off, such as connecting via workgroup manager from administration machines. Not to mention this isn’t what should be happening anyway. And again this A record just changes within Windows DNS, so I don’t know if its something in windows or something else causing it to change.

tom

[trice]

I usually make the folder locally on each machine – the following commands should do the trick

mkdir /iMovie\ Events.localized
chown root:admin /iMovie\ Events.localized
chmod 1777 /iMovie\ Events.localized

All users will be able to write and edit the contents of the folder but not delete the folder itself. We’re not overly concerned with the security of the contents of this folder (if need be users are reminded to move their info someplace else after its imported) so we don’t normally take any precautions beyond this. In fact the contents of this folder are regularly purged, via a login/logout hook if need be.

Using ARD’s send unix feature these commands can be easily sent to all your machines at once.

tom

[trice]

It did work on some Tiger machines. The only difference I saw was that in Leopard, the folders in the tmp directory got created with the user’s shortname while in Tiger they got created with the user’s UID. Obviously in order to set this up, it had to be done from a Leopard Client. This problem doesn’t seem new to this feature either. For example if anyone has used Server Cleanup by Marc Garbenas, (great little piece of software by the way) then they might be familiar with this problem. For whatever reason on seemingly identical Tiger machines sometimes individual folders will get created in the tmp folder and sometimes they will not. Wondering if anyone knew of any rhyme or reason.

tom

[Author]

Posts