[mosx86]

[QUOTE][u]Quote by: MacTroll[/u][p]The man pages and openldap.org is probably where I would start.

The O’Reilly book on LDAP isn’t a bad overview, although it doesn’t get very advanced.

Having said that I don’t think your problem has much to do with LDAP.

To ensure that you can slapcat both databases and then diff the outputs. As far as slapcat being broken, that’s specifically around using SSL certs that require a password IIRC.

For your failover issues I’d start looking at the OD client config record in cn=config in the LDAP db and making sure that it lists the master and the replicas correctly.

After that I would do a tcpdump from a client and then pull the cable on the master. See what happens.[/p][/QUOTE]

Thanks for the starting points…

One thing I forgot to add, is that the replica functions properly while the master is online and will authn/authz just fine. Only when the master goes down does the replica fail.

Here is my ldap entry for the replica (IPs obfuscated):

dn: cn=ldapreplicas,cn=config,dc=xxxx,dc=yyy,dc=zzz
cn: ldapreplicas
apple-ldap-replica: ldap://ODmaster.IP
apple-ldap-replica: ldap://ODrep.IP
apple-ldap-writable-replica: ldap://ODmaster.IP
objectClass: apple-configuration
objectClass: top

Here it is in dscl:

apple-ldap-replica: ldap://ODmaster.IP ldap://ODrep.IP
apple-ldap-writable-replica: ldap://ODmaster.IP
cn: ldapreplicas
objectClass: apple-configuration top
AppleMetaNodeLocation: /LDAPv3/FQHN.OD.master
LDAPReadReplicas: ldap://ODmaster.IP ldap://ODrep.IP
LDAPWriteReplicas: ldap://ODmaster.IP
PasswordPlus: ********
RecordName: ldapreplicas
RecordType: dsRecTypeStandard:Config

I’ll take a look at slapcat’ng both the master and replica after hours. Thanks again…

[mosx86]

[QUOTE][u]Quote by: MacTroll[/u][p]You have some specific action in mind?[/p][/QUOTE]

Above wanting to wrap my head around the ldap toolset better, I’m looking into an issue where our OD replica does not fail over should our OD master become unavailable. I don’t see any errors in the replication logs, but I do see an error via ServerAdmin for slurpd. I’ve been reading some discussions on slapcat failing in 10.4 <http://lists.apple.com/archives/Macos-x-server/2006/Aug/msg01055.html> and am wondering if it may be related.

We’re running 10.4.9 Server on both the master and replica.

[mosx86]

[QUOTE][u]Quote by: jpons[/u][p]Right, I want to control from the OD who can ssh into a machine just like I can control who can log in via afp or the console.[/p][/QUOTE]

Probably not the answer you’re looking for but you may have to edit a file on the clients to restrict access. Are your machines imaged?

http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Restricting_User_Logins.html

[mosx86]

Oops, completely misread that… with my original answer…

To verify, you want to limit ssh access to client machines?

[QUOTE][u]Quote by: jpons[/u][p]I was wondering if someone could enlighten me about wether this is even possible and if it is how can I accomplish it.

I set up an OD and for the time being are trying not to run kerberos services.

I also have a number of OSX Client machines that are bound to the OD.

Using Workgroup Manager under the “Accounts” section I can create a “computer list” that contains any number of OSX client machines and restrict access to those machines based on user groups.

This allows me to restrict AFP and console access to the machines in the group, however it seems that ANY user in the OD can still ssh into the machine.

Is there a way to fix this so that I can completely control who has access to those machines?

Client machines are OSX 10.4.10
Server Machine is OSX Server 10.4.11

I would appreciate any help on this issue.

Thanks,

-J[/p][/QUOTE]

[mosx86]

[QUOTE][u]Quote by: MacTroll[/u][p]Sadly PWS doesn’t currently have that functionality.

The only way, and this is ugly, is to packet trace where the requests are coming from.[/p][/QUOTE]

Man, that is ugly. Hope its added to Leopard because it would come in really handy…

Can you recommend any packet sniffer? Have only done a limited amount of that…

[mosx86]

[QUOTE][u]Quote by: MacTroll[/u][p]Your FQDN match up with the IP address that you’re using?
[code]
host yourname.com
[/code]
Would tell you what DNS is resolving it to.[/p][/QUOTE]

Yeah, I’ve done both forward and reverse lookups on the host and server… Everything pans out. Single signon is working fine for AFP, and mail. The server appears to be handing out addressless tickets which is the workaround for NAT issues…

[mosx86]

I’ve been told that the error is mostly like associated with NAT, unfortunately– I’m not using NAT, however I would like to take a look at the server IP address in the ticket’s I’m assigned. If I inspect the tickets in Apple’s Kerberos.app, it gives me the FQHN. Does anyone here know how to view the actual IP?

[mosx86]

Some further info:

When attempting the connection I’m granted two tickets from the KDC so it appears that authentication is successful. However, the error reported is that I’m using the wrong principal. Also of note, the kdc.log is empty. Has apple redirected kdc.log messages to another log file?

Principal: [email protected]
Service: ftp/[email protected]
Version: Kerberos V5
Status: Valid

Flags:
Forwardable: Yes
Forwarded: No
Proxiable: Yes
Proxied: No
Postdatable: No
Postdated: No
Invalid: No
Renewable: Y es
Initial: No
Preauthenticated: Yes
Hardware Auththenticated: No
Is S-key: No

IP Addresses: None

#####

Principal: [email protected]
Service: host/[email protected]
Version: Kerberos V5
Status: Valid

Flags:
Forwardable: Yes
Forwarded: No
Proxiable: Yes
Proxied: No
Postdatable: No
Postdated: No
Invalid: No
Renewable: Y es
Initial: No
Preauthenticated: Yes
Hardware Auththenticated: No
Is S-key: No

IP Addresses: None

[mosx86]

First off, thanks for the quick reply… The replica appears to be working fine.

May 2 2007 13:49:42 LISTREPLICAS: IP.of.OD.master requested the replica list.
May 2 2007 13:49:42 SYNC SESSIONKEY: gmt skew is 0
May 2 2007 13:49:42 SYNC PUSH: writing to /var/db/authserver/syncfile1178138982.344170.gz
May 2 2007 13:49:42 SYNC PROCESS-NO-REPLY: success
May 2 2007 13:49:42 QUIT: {no user} disconnected.

I’m more curious as to why the error is being generated. Any suggestions of what to look for?

[mosx86]

[QUOTE]3. XP clients are able to bind to the domain. When users attempt to authenticate an error is returned that the domain is unavailable.

4. Related to problem 3. Some hosts that are able to authenticate users occasionally lose this ability. Typically a restart will correct the issue.
[/QUOTE]

This may help some people down the road… After doing some more research on SAMBA PDC’s I’ve learned that PDCs don’t like it when there are workgroups on the network with the same name as the domain. Also, netbios names that match the domain can cause the PDC to act up as well.

[mosx86]

[QUOTE][u]Quote by: papastanley[/u][p]I haven’t had a solution yet – had to leave it and run with what I had, time was getting too tight.

I did however find this (link below) which maybe has some bearing, but didn’t fix my problem though – you mention the SID issue – this shows you where to check if [b]all[/b] the SID entries are matching. There may be two plists which don’t match – perhaps a bug with the SMB controls in WGM not writing to both plists?

Mine were not matching, but once I fixed them the problem still remained. Cannot authorise a domain join from a Windows XP box.

FYI in case this helps your situation…

[url]http://www.radiotope.com/writing/?p=61#comment-1440[/url]

My fallbackplan is to use pGina instead of the Windows login, and point it at the LDAP server on my OS X box.

I’ll let you know how this works when I get to it.

good luck!

.:S:.[/p][/QUOTE]

Thanks for the suggestion and link. One of the plists in WGM did not have the proper SID. After that I was able to promote the SMB service to PDC using my diradmin username and password and can now bind windows hosts to the domain.

[mosx86]

I am having a similar issue which started after I changed the domain name of the PDC.

Steps I’ve taken to correct the issue include:

Rolling the PDC back to standalone server and then promoting back to PDC.

Removing the /etc/smb.conf, /var/samba, and /var/db/samba/secrets.tbd files and reconfiguring the server from scratch.

Creating a new directory admin users to attempt binding with.

All have been met with no success.

My server and domain SID’s match.

One [url=http://lists.apple.com/archives/macos-x-server/2005/Aug/msg00621.html]solution[/url] that I have seen floating around is this::

/usr/bin/opendirectorypdbconfig -c set_authenticator -r admin-name -p xxxxx -n /LDAPv3/127.0.0.1

I haven’t had a chance to give this a try as the man page for opendirectorypdbconfig is no help in trying to figure out the flags. I’m assuming admin-name is the username for your diradmin account and I’m not sure if there’s a way to have the command prompt for the password rather than including it in the command.

Perhaps someone here has worked with this…

[mosx86]

[QUOTE][u]Quote by: brnlahaze[/u]

I am seeing the same problem on my machine.

I am running 10.4.8 on this server. When I came in this morning my AppleFileSericeEror.log was 3.01GB.

[/QUOTE]

Same thing here… Not sure what triggered it yet, but our log was 2.9 GB and AFP was taking approx 100% of the proc.

[Author]

Posts