[honestpuck]

Art (and Mike)

Unfortunately OS X does not consider copying a file as ‘creating’ so the umask is ignored and the files and directories get the same permissions they had on the original volume.

Apart from the two solutions you’ve already suggested the only other one I’ve come up with is a cron job that changes the permissions.

Frankly, why not create a droplet that copies the files to the right folder on the client computer and then changes the permissions so that it is all one step. Shove it on the users desktop and Dock then they’ll just consider it a one step process, just as it is now.

Tony

[honestpuck]

Sid,

What will you be browsing the records with? Most LDAP <-> language modules support the full capabilities of ldap_search() which supports filters, so you just need to set a filter for something such as “(group=staff)”.

Tony Williams

[honestpuck]

Dave,

1/ For a Slave you only need to point it at a working DNS, it doesn’t need to have DNS running on it. You only need one (or prefereably two) DN servers in a net.

2/ slapcat is a command line utility to dump all or part of an LDAP database to standard out in LDIF format. ‘man slapcat’ at the CLI prompt for details but I find it useful to just do a quick dump to see if the LDAP server is nicely populated.

Tony

[honestpuck]

Obery,

You said :-
[QUOTE]
This must have something to do with the manner that the other OS X services interact with the directory service.

It’s just freakin’ strange…
[/QUOTE]

I had a hard think about this when you first posted but didn’t come up with any concrete suggestions.

I was thinking something similar about the interaction of other services. It’s my bet that you have some process that wants to do a check on a username that isn’t set up for a user bind and is making multiple attempts due to the failure of an anonymous bind. I haven’t checked the doco but I’d suspect some part of the mail receipt process, perhaps.

I’d love to see all your logs – I bet there’s a log entry somewhere that mentions an LDAP failure, repeatedly.

Tony

[honestpuck]

OK, if your server is a replica have you made sure that you’ve already pushed the directory information from the master to it?

Log on and try something like a ‘slapcat’ to dump out the LDAP server records. That should show you if you have the information.

If that seems OK then try logging in via ssh from a client that is pointed at your replica. If that works then on your client try getting a Kerberos ticket. If that works then try mounting an AFP share as the user you have a ticket for. then try logging into the client as a network user.

But from you’re original post that these servers are for home directories then they are only for AFP so I’d make them Slaves if i was you. No point in having them as Replicas.

Tony

When you see which of those bits work and not work you’ve got a better idea where you’re broken.

Tony

[honestpuck]

Dave,

You said:

[QUOTE]
I Should rephrase that…What if I want my server to be connected to a directory service?
[/QUOTE]

Ok, short explanation of how OD works. An OD Master sits at the top of the tree. A LAN/WAN should only have one of these. An OD Replica is a copy of this that can be used to take the load off the Master or as a LAN copy of a WAN OD Master (I have a Master in one city and a Replica in another city, for example). An OD Slave is a server that does not offer any directory services at all but uses another server (either Master or Replica) to authenticate users for services such as mail serving and file sharing.

So if you want a server to be used only for stuff other than authenticating use Server Admin to make it an OD Slave and point it at your OD Master. Job done.

Just to make this reply topical to the DNS section – make sure that your DNS server has both forward and back entries for your OD Slave. In fact, always make sure every server you build has forward and back entries in your DNS before you do the Server software install, it makes life so much easier. Oh, and when doing the Server install just point them to your DNS boxes as if they were a client.

Tony

[honestpuck]

Jeff,

Not sure what you’re problem is. If you run Server Admin and then go to the Help menu and select ‘Server Admin Help’ it should open it up in the Help Viewer no problems.

If that doesn’t work I suggest you reinstall the Admin Tools.

Tony

[honestpuck]

DragonMac,

The second Kerberos article has all the command line commands you need, already outlined. Go and read the ‘man’ pages for each and you will understand exactly what Joel is doing. The only ‘rm’ command you need to do is the one he tells you to use. The second article is as close to ‘a straight set of CLI commands’ as you are going to get.

On the no users in the database issue. If you hand crank the KDC then you won’t have any user principals in the list until after they change their password, or you do exactly as you have outlined and change the password type. If you want to get around this problem then you will have to demote the server from ‘Open Directory Master’ and then promote it back, which will also blow away your LDAP database and require you to re-import or re-enter your user list. It’s the password part of Open Directory that keeps the three user and password lists in sync.

There is only one edu.mit.Kerberos file, it should be exactly the same as the one on your server, but your clients should be grabbing it from your LDAP server if all is working fine.

If you’re having this much trouble and feel uncertain about using the CLI I suggest you get a second box for a couple of days and do the server install from scratch a couple of times and go through the steps in the Kerberos article here reading as much of the documentation as possible as you go. If you do the OS X Server install fine (making sure you are connected to a good DNS that lists your new server box properly is the key step) then getting Kerberos up is trivial – it just works. Then when you’re confident do a brand new, clean install on your server. The extra work might hurt at this end but you’ll have a lot less problems keeping the box running.

Tony

[honestpuck]

Hi,

First, the two articles are a great guide to building Kerberos from the bottom up. Just do the steps one by one – making sure to check your keytab and list of principals at every step.

Second – you should NEVER create a principal for root@ – that would allow root access via the KDC – root/admin@ is the principal that allows root to administer the KDC and it should be there.

Third – You are probably better off to ignore the Kerberos GUI utility until you are sure the system is working perfectly. Use the command line utilities. On your server do an “apropos kerberos” to get the full list of them. The same goes for cleaning out the KDC, do it in the command line making sure you clean the right places out prooperly by doinf an ‘ls -a’ so you can see any files starting with a period.

Fourth – check out ALL the doco of ALL of the commands in the second Kerberos article so you understand what each command is doing.

Fifth, make sure as much works on the server as possible before trying anything from a client and ABSOLUTELY confirm that the edu.mit.Kerberos file is the same on the client and server.

Finally, a Kerberos rebuild should not upset your user list at all, the users are stored in the LDAP server and the system replicates them into the KDC, before you try and fix your KDC make sure you have LDAP system working perfectly.

After that, if you are still having problems then I suggest you write a careful post that tells us as much information as possible, including your edu.mit.Kerberos file and the right parts of the keytab and principal list.

Tony Williams

[honestpuck]

The folders are created under the default server "Groups" folder. I’ve tried it as just ordinary folderrs and getting the Group to point to them as the groups default folder.

It turns out that the problem is the length of the groups short name. While ‘WorkGroup Manager’ will accept a group short name longer than 8 characters the system just silently fails if it is longer. Nice one, Apple. Of course exactly the same name worked fine under ASIP 6.3 and Apple’s Migration utility failed to either adjust the name or give us a warning. The XML import in WorkGroup Manager also failed to advise of the problem.

Tony

[honestpuck]

Joel,

No, server_b is not a KDC. I only want to run the one KDC.

I figured out the problem. I’d created the principals for server_b on server_b so the keytabs on the two machines were different. Creating the principals on server_a and then copying the keytab from server_a to server_b fixed it.

Doco is a bit thin on the ground for this sort of thing. I’m going to have to write it up myself, I think. <g>

Works a charm.

Tony

[honestpuck]

Curtisf,

Yeah, I was afraid of that.

I thought of a separate net but shoehorning just the spare server out of my setup was hard enough – finding another three is downright impossible.

The really frustrating thing is that if I get all this stuff working right I get three spare eMacs that are currently wasted as Timbuktu ends.

I might have to go on bended knee to my reseller and borrow a key for a month or two.

Thanks,

Tony

[honestpuck]

That is wierd. You’re getting three tickets all at the same time.

Why are you not getting host names in your tickets? I think you’ve got something wrong with your setup.

My tickets on a client look like this

klist
Kerberos 5 ticket cache: ‘API:Initial default ccache’
Default Principal: [email protected]
Valid Starting Expires Service Principal
06/25/04 11:28:55 06/25/04 21:28:55 krbtgt/[email protected]
renew until 07/02/04 11:28:55
06/25/04 11:29:19 06/25/04 21:28:55 host/[email protected]
renew until 07/02/04 11:28:55
06/25/04 11:34:32 06/25/04 21:28:55 afpserver/[email protected]
renew until 07/02/04 11:28:55

Notice how I’ve got the server name on both sides of the service tickets and on the right side of the login ticket. You’re missing that and this makes me suspect something seriously wrong with the setup.

Check your edu.mit.Kerberos file and then blow away the keytab file and /var/db/krb5kdc directory and build it from scratch by hand.

Tony

[honestpuck]

Well all that looks hunky dory.

Hmmmm.

Are you getting the first ticket from Mail.app or at login? That ticket list you show there has no service tickets so I assume that was just at login as otherwise you’d have a pop or imap ticket.

What do the tickets look like when the kerberos app is reporting two tickets for the same user?

Have you tried multiple logins with ssh or sftp to see if they generate the same problem?

Just trying to think of ways of isolating exactly what part of the system is generating the problem.

Tony

[honestpuck]

bustthis,

If you go to the KDC machine and do a plain ‘sudo klist’ what exactly are the tickets you’re seeing.

I had a problem similar to this when the KDC was on a machine with two DNS names and the realm was not the canonical one. A principal list showed that it had principals for both names and it sometimes issued duplicate tickets.

Tony

[Author]

Posts