[jdyck]

I’m having the same problem, for whatever that’s worth. Seems like no matter what I do (even to the point of creating a Dock.plist file and putting it into the User Template file so that any new users automatically get that Dock) there are always a few extra apps showing up that aren’t in the WGM list – in my case it’s down to Time Machine and the Downloads folder. Haven’t been able to figure out how to get rid of them yet.

[jdyck]

Just want to confirm that Leopard is NOT caching AD group membership. I had this same problem but a little different in that all my MCX settings assigned to an OD group with AD groups as members work ONLY while I’m plugged into the network. As soon as I take the machine out of the network I lose all my MCX settings. Exact same setup, same OD group, but with an AD USER rather than a GROUP and it works fine. Definitely something screwed up with Group membership caching, will be filing a bug today.

[jdyck]

I got this resolved by putting any troublesome applications into a folder and whitelisting the folder. Not the most elegant solution I suppose, but it works and that’s what really matters.

[jdyck]

I’ve regenerated my image and for whatever reason it works now, so guess this was just an odd glitch.

[jdyck]

Hey Joel,

That kinda makes sense, but I’m still trying to figure out why it works fine on the other setup I did (authenticating AD users over SSL, but with private CA cert installed on clients)… As well, if I install the Intermediate CA from GoDaddy on a client machine then it also works… Because of that I’m not quite sure this is the answer.

Jeff

[jdyck]

OK, I’ve figured out a bit more about this…

Basically I setup a test network with my own OS X Server and setup DNS so I served the same domain, then installed ther certificate there and everything worked fine. I then setup the iChat server on site from scratch again – complete reinstall, transfer the buddy lists, reinstall the cert and the same problem happens – I get the insecure login message.

*HOWEVER,* after much thought about what else might be different, my test system was using OD accounts, the production system is authenticating via AD users. Sure enough, if I create an OD ichat test user and login, there is no insecure login message.

This would seem to indicate that for whatever reason SSL logins aren’t supported when authentication AD users…. Except this is the second district I’ve set this kind of thing up for – iChat authenticating AD users and I didn’t have the problem at the first location. The only difference between the two is this District uses a GoDaddy Intermediate signed CA, whereas the first used a cert signed by it’s own CA, with the CA installed on all client computers.

Any other ideas with this bit of extra info?

[jdyck]

Hello all,

First of all, huge thanks to those who have taken some of their valuable time to offer suggestions to date. I was distracted by a completely unrelated issue for a while but am back to this cert thing. I’ve done some further sleuthing and Googling trying to figure this out but am still a bit stumped…

I did find the actual cert files in /etc/certificates where there were actually 5 files with the FQDN of the cert, each with different extensions and data within:

FQDN.chcrt – seems to contain the GoDaddy Intermediate Cert, and an unknown cert (guessing GoDaddy root?).
FQDN.crt – Contains the iChat cert
FQDN.crtkey – Contains the iChat cert, the iChat private key, and the GoDaddy intermediate cert.
FQDN.csr – The certificate signing request
FQDN.key – Contains the iChat private key.

I also found the jabber.xml config file in /etc/jabber/, which had two interesting entrees (Note: I had to replace all the greater than / less than symbols with ( and ) symbols, as this forum system kept trying to convert them to code, which meant that without the change wide chunks of this just didn’t show up.)

Anyway, about halfway down was an entry defining which IP/ports to listen to, followed by the ssl ports, as follows:

(!–
The (ssl/) tag acts pretty much like the (ip/) tag,
except it defines that SSL is to be used on the
ports and IP addresses specified. You must specify
an IP address here, or the connections will fail.
–)
(ssl port=’5223′)0.0.0.0(/ssl)

Then near the very end is a section that defines the ssl certificates to use, as follows:

(!–
The following section initializes SSL for top-level I/O.
This works only when the server is compiled with openssl!
Use IPs here or connections will fail.
–)
(ssl)
(key ip=’0.0.0.0′)/etc/certificates/FQDN.crtkey(/key)
(/ssl)

(!–

The first thing that jumped out at me is that both of these have 0.0.0.0 instead of actual IPs, I did a bit of a search on the Internet on jabber.xml and any examples I found online had real IPs in this spot, so I backed up the XML file and edited the original to contain the real IPs, then went into Server Admin and stopped the service. I noted that Server Admin no longer showed the iChat cert, so I tried starting as is and then logged in from iChat, only to get the InSecure login message. So I shut down the service, selected the iChat cert, and restarted the service again, but still get the insecure login message, so as promising as that seemed it still doesn’t resolve the problem. Note that the iChat service DOES still work after changing the IP address though, so I didn’t wreck anything at least.

In summary, what I’m getting from all of that is that the jabber server is configured to be using the FQDN.crtkey file, which appears to contain the iChat cert, private key, and the Intermediate CA cert, which is what I thought was missing from the equation. Yet things still aren’t working… Am I missing something obvious here?

Finally, I’m wondering how the files in /etc/certificates relate to the certificates in KeyChain Access? I tried exporting my iChat certificate and don’t get the same file I see in /etc/certificates so wonder if the issue may lie there somehow.

Once again, any advice or ideas offered are greatly appreciated.

Jeff

[jdyck]

Thanks for the very quick reply (as normal) Joel. I’m beginning to think I don’t understand SSL Certs half as well as I thought and I’m having a hard time wrapping my head around this….

Following your advice I did some Googling on the openssl s_client and ran the following command, with the following results….

—————

openssl s_client -connect ichat.csf.bc.ca:5223 -showcerts

CONNECTED(00000003)
depth=0 /O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
verify error:num=27:certificate not trusted
verify return:1
depth=0 /O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
verify error:num=21:unable to verify the first certificate
verify return:1
—
Certificate chain
0 s:/O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
—–BEGIN CERTIFICATE—–
MIIE9jCCA96gAwIBAgIDQVzhMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
UzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UE
ChMRR29EYWRkeS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0
ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2Vj
dXJlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzAe
Fw0wNzEwMTExOTQ3MTdaFw0xNzEwMTExOTQ3MTdaMFcxGDAWBgNVBAoTD2ljaGF0
LmNzZi5iYy5jYTEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRgw
FgYDVQQDEw9pY2hhdC5jc2YuYmMuY2EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAMvqmxDypWzt34IkZl2U0IZuekevLN36YhyJa+kApJI5fFvHk1pDnscN/A+l
Ab+zUQq2K8EtZTqX68GOsIfrZ8zN5f2yfzvIa5W+uD/w4keaixtgxQkvMNA4o5kD
IyXTA79yPBLetASSSk5UF4kQVCh04k81/KCs9kwP+TLatufhAgMBAAGjggHZMIIB
1TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwVgYDVR0fBE8wTTBLoEmgR4ZFaHR0cDovL2NlcnRpZmljYXRlcy5n
b2RhZGR5LmNvbS9yZXBvc2l0b3J5L2dvZGFkZHlleHRlbmRlZGlzc3VpbmcuY3Js
MFIGA1UdIARLMEkwRwYLYIZIAYb9bQEHFwEwODA2BggrBgEFBQcCARYqaHR0cDov
L2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MH8GCCsGAQUFBwEB
BHMwcTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wSgYIKwYB
BQUHMAKGPmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9y
eS9nZF9pbnRlcm1lZGlhdGUuY3J0MB0GA1UdDgQWBBRh7r7skL8P+WvikKRZIYId
8KrZxjAfBgNVHSMEGDAWgBT9rGEyk2xF1uLuhV+auud2mWjM5zAvBgNVHREEKDAm
gg9pY2hhdC5jc2YuYmMuY2GCE3d3dy5pY2hhdC5jc2YuYmMuY2EwDQYJKoZIhvcN
AQEFBQADggEBAI/YcysIdD+jUNONFJICuH1AMTJOdVgnGAMSqAtG1eeJtUnH4AkH
JnEgcur7+zjxcBi1POcoJ2VDUdXjWo3uX96MvI0tCMsqyVLPv6adkIIg8h8NBdh6
bqDGXp30VCkMa3lpmnmB8Nt+B1wsBgZUad7t6KArpaV5/qvcllzTTKpxVXvZgYJk
JJn39fEToecj9TM1319qWASAN/FqxP4Z9E5vZ42qPyt8nd9etlM8C9UJ/hNgahlT
6KIfnMV7ZOhcak3mvQAVuiSVjQUC56RVHJIkSWs9q8D4iAoFnIZWhislloK5PnOk
G/1//87s2X4a88cA8QmGjscyB+Al6AMj6S8=
—–END CERTIFICATE—–
—
Server certificate
subject=/O=ichat.csf.bc.ca/OU=Domain Control Validated/CN=ichat.csf.bc.ca
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
—
No client certificate CA names sent
—
SSL handshake has read 1436 bytes and written 316 bytes
—
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: FF956734ACC23BE51050AFE432DCEB177A334135DAF2C3E298AA4749CEA2C4BF
Session-ID-ctx:
Master-Key: 132978C0E4D256630A9024117988EE02FCEB4A440C7447ADC98F6E7232395DE961399A0927EF219406E4275ABEDF7761
Key-Arg : None
Start Time: 1192386966
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
—

Other than the two notes about “code 21: unable to verify the first certificate” notes I don’t see too much else in there, although gotta confess I’ve never looked at the output of this command before so not entirely sure what it *should* look like. I just ran it against my banks ssl site and get “code 20: unable to get local issuer certificate”.

I did try adding the intermediate cert to a client and that did stop the message, but again, that kinda negates the whole point of buying a cert, when I could have accomplished the same thing by self signing a cert with their existing CA.

You mentioned combining the intermediate and server cert together and manually configuring the jabber server – any more details on how I would do that? I presume I can just do a cut and paste to combine the certs, but then how do I configure the jabber server? I’m presuming this is not the config through the Server Admin GUI that just lets you choose the cert to use. I tried looking into the /var/jabber/ folder last night to see if I could find the config files, but I can’t get into sudo so will have to get the root password when I’m back there on Tuesday. Can you configure it that way or am I barking up the wrong tree? One of the .crt files I have from GoDaddy is an ‘intermediate_bundle’ file that when I open in Text Edit looks to be three certs pasted in.

Also, could you clarify what the difference is between installing these certs into the System part of KeyChain Access verses the x509 part? When I installed the CA into the clients at my last location it went into x509 Anchors, but the GoDaddy instructions for the server say to install into the System area. I’m not entirely certain of the difference.

—–

I’m also going to quickly detail what I *have* done to make sure I’m not making a mistake.

In Server Admin -> Server Name -> Settings -> Certificates created a cert, requested a signed cert and drug the little cert icon to the Desktop. Submitted that cert to GoDaddy and received the signed cert, went back into Server Admin and clicked the Ad Signed Certificate and pasted their verification code into it. Then installed their Intermediate.crt file into the System portion of Keychain Access. Then configured the iChat server to use the newly created cert and restarted the service. Am I missing something here or doing something wrong?

Anyway, once again, any assistance offered is greatly appreciated.

Jeff

[jdyck]

OK, I have tried a few more things without much luck (I’m perhaps seeing a few less errors, but hard to tell for sure since a lot of our users are now away for summer vacation)…

• I updated to 10.4.10 server.
• I bypassed the OD group of nested AD groups and added the AD groups directly to the Service ACL.
• I have also got a GB switch on order, which will be used to connect all our higher throughput servers, so when this is installed the OS X Mail server should have GB communication to the AD server it authenticates against.

I’ve tried doing the memberd cache thing, but have to confess that I’m not sure how to read the results of this command to give me any information about the problems I’m seeing… When I run the memberd -l command and check the memberd_dump.log I get a big list with tonnes of entrees like:

2007-07-09 11:45:17 PDT Group ‘mhofstrand’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mhofstrand’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mhofstrand’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mhofstrand’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mhofstrand’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mhofstrand’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mhofstrand’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mhofstrand’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mmiller’ not found by name (result added to cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)
2007-07-09 11:45:17 PDT Group ‘mscheck’ not found by name (result is from cache)

I have been watching my logs a lot and searching for the problem, and do notice that it always seems to happen in batches – ie: for a few minutes here and there several times throughout the day. Can’t see any rhyme or reason as to the times though, but the fact that it happens intermittently but in batches might mean something to somebody…

I’m going to leave this open for a bit longer to see if anyone has any further information or ideas, but I think if I can’t get this working more reliably I’m going to have to move us to an Exchange server (just kidding) – I’ll probably have to modify the AD schema to include the AppleMailAttribute and populate that. I’d rather stick with Service ACLs though as they seem a lot simpler to implement and maintain.

Thanks again for anything offered.

Jeff

[jdyck]

Anybody? I’m just about ready to order a fancy new X-Serve for this, but am hesitant if it’s going to mean that much maintenance work as people leave…

[jdyck]

I think I’m having the EXACT same problem as you and I’m completely stumped… We recently created a new domain, I’m at one site and have successfully bound several client machines to the new Domain with no problem. However, I have a Tiger server on site that we use for imaging and want to use as an OD replica that I cannot bind to the new domain…
I just reloaded the whole server OS and tried to bind with the exact same problem… I’ve tried giving the machine a new name (including removing the old DNS record and creating a new one with the new name, and running the changeip command to make sure hostnames were all good…).
I’m stumped… the only message I get from Directory Access is that an “Unknown error occured…” The computer account *IS* created in the AD Domain, but the DirectoryService Error log stops with two lines stating that it was attempting to change password, so I’m wondering if that is failing for some reason… I am a Domain Admin so my account shouldn’t have any permission problems I don’t think…
Help anyone?

[jdyck]

Just browsing by trying to find an answer to a problem I have, but figured I’d offer you one tidbit I’ve found has helped me…

Have you tried forcing the SSO config… Go into terminal on your OS X Server and enter:

sudo dsconfigad -enablesso

Hope it helps.

Jeff

[jdyck]

OK, I’m back – it’s been a hectic couple of weeks getting ready for the start of the school year, and I finally got a chance to get back to this today – think I’m close, but it’s not quite there yet. Any input/ideas/suggestions would be greatly appreciated.
What I’ve done so far:
First of all I downloaded LDAPPER and tinkered around to figure out the settings until I was successfully able to browse and search through the AD directory. Essentially just the IP address of the server, the search base = dc=fully,dc=qualified,dc=domain,dc=name kinda thing, and authenticating with an admin account.

The iChat server is already bound to the First AD domain via the ADplugin, and that is working fine…
So then I went into Directory Access on the iChat server and created a new LDAPv3 with the following settings:
Connection: Added server IP, no other changes (ie: SSL, custom port, server refrals, etc all off).
Search & Mappings: Access this LDAPv3 server using Active Directory, edited the “Users” search base to look in the whole directory rather than just Users, since otherwise I don’t see the users in all our OUs. Everything else left as is.
Security: Turned on “Use authentication when connecting” and added a Distinguished name in the form of “[email protected]” – all other options are left off.
Then I went to the Authentication tab and added the new LDAPv3 setting so that it is between the First AD domain and 127.0.0.1. I clicked Apply.

I can now drop into the Terminal and do a dscl localhost and cd to /LDAPv3/IPAddress/Users, and ls will give me a list of users. However, if I try to read the properties of a user I get the following error…
2006-09-08 14:36:19.376 dscl[1420] *** My Uncaught Exception: ([DSoDataList initWithDir:value:] value is not a valid NSString nor NSData)
I can go into Workgroup manager and browse both the users and groups of the new domain, I can even drag a user/group from new domain into the Access permissions of a file share… I can even go into Server Admin and find the users as part of the Service ACLs lists… However, if I actually try to login to a fileshare I get an error that “Connection Failed. Unknown user, incorrect password, or login is disabled. Please retype the name and password or contact the server’s administrator.”
It almost seems to me like the user/group names are coming through, but not the properties, so things like passwords aren’t working…
Any ideas?

[jdyck]

I went through some similiar issues with having difficulties binding computers to Active Directory… Turned out to be a Domain Controller issue, but one of the things that helped me enormously in figuring out was to enable the DirectoryService logging by going into the Terminal before binding and typing “sudo killall -USR1 DirectoryService”. After you try binding to AD you can then go into Console and choose the /Library/Logs/DirectoryService/DirectoryService.debug.log.
I found there was a lot of great info in that log that helped me trace the problems down. In my case the poor computer was trying all over our slow WAN to try and find a server to bind to, when there was a domain controller sitting right next to it. Brought in our AD guru and he found all kinds of things wrong with the DC, rebuilt it from scratch and now everything is fine and beautiful in AD land.
Hope that helps.
Cheers
Jeff

[jdyck]

Thanks for your response MacTroll. I will speak with our Active Directory guru and see what he can figure out… I probably doesn’t help that our AD setup is in flux the last month as they try to fix the mess from the previous ‘gurus’… Will post an update if this does or does not fix things.

[Author]

Posts