Hello.

couple of questions for our AD-experts out here

Im having some problems rolling out SCOM to our web-servers which are on the dirty-side of the company firewall.. the ports that are required by SCOM are open, but it still is not working due to failing kerberos authentication and not being able to see the SPN.

The servers are in separate child domains of the same forest root... so the scom server is in domainX.XYZ.local and the web servers (along with some others) are in domainY.XYZ.local

Now all the other servers in domainY that are inside the firewall are working ok.

Im wondering if because the SCOM box is in domainX that the servers are trying to contact a DC in domainX rather than domainY?? (the firewall permits them to contact the DCs in domainY)

any ideas?. ovbiously its impossible to set up a test environment and i cant go opening ports in the corporate firewall either

Thanks in advance

Can you get at the firewall logs and see if anything is getting blocked between the machines concerned?

What firewall is it?

Have you got the Agent's installed on the Webservers Col? if not, try a manual install of the agents after tweaking SCOM to accept a manual install. That has worked for me before after a similar problem.

Have you got the Agent's installed on the Webservers Col? if not, try a manual install of the agents after tweaking SCOM to accept a manual install. That has worked for me before after a similar problem.

The agents were a manual install anyway with them being firewalled.

the message in the eventlog is this:

Failed to initialize security context for target MSOMHSvc/scomserver.domainx.xyz.local The error returned is 0x80090311(No authority could be contacted for authentication.

). This error can apply to either the Kerberos or the SChannel package.

Its a PIX firewall. getting logs is a PITA because its not managed by us.

Have a look here Col, it could be something simple like local admin rights for the action account. It also has to be able to resolve names using DNS or the Hosts file both ways or authentication can fail.

System Center Forum - OpsMgr 2007 PKI and Gateway Scenarios Part 4: Troubleshooting Mutual Authentication

Have a look here Col, it could be something simple like local admin rights for the action account. It also has to be able to resolve names using DNS or the Hosts file both ways or authentication can fail.

System Center Forum - OpsMgr 2007 PKI and Gateway Scenarios Part 4: Troubleshooting Mutual Authentication

Cheers for that Tony... the servers can resolve both ways, (i can telnet to 5723).

problem is we dont have a CA in our forest, so i need to use kerberos.. :(

I think if the server is in domain x, then it needs to be able to communicate with DC that is part of domain X. You may need to open a couple of ports across the firewall to get it working. We had to do the same with out frontend exchange server for authentication.

I think if the server is in domain x, then it needs to be able to communicate with DC that is part of domain X. You may need to open a couple of ports across the firewall to get it working. We had to do the same with out frontend exchange server for authentication.

Ok... looks like ill have to do some more research then.. might have to look into the CA route as i think people will be getting a bit jumpy about opening ports right left and centre

Ok... looks like ill have to do some more research then.. might have to look into the CA route as i think people will be getting a bit jumpy about opening ports right left and centre

An internal CA is not to difficult to run with and makes this kind of thing a lot easier were firewalls are concerned mate, especially if you don't have complete control of the firewall.

An internal CA is not to difficult to run with and makes this kind of thing a lot easier were firewalls are concerned mate, especially if you don't have complete control of the firewall.

Yeah.. im beginning to see that now looking at the number of firewall rules i cant see where the problem is (all the ad ports are open and i can log on with domain creds) will just go the CA route i think... ill do it myself instead of trying to pursuade AD monkeys to do it for me... that document you linked to up top makes it pretty straightforward..

Cheers for the help

Col, if you have access to the boxes on either side, what about having a look at the network traffic with wireshark?

I had an AD domain issue with Kerberos authentication with COM+ components - all clients on local domain could access, but all those on the customer's domain couldn't. Turned out to be a two-way trust problem and that we hadn't added the customer's accounts in to the local database users group on the server with the COM+ modules.

But we were confused why it didn't work, and thanks to wireshark, noticed that when talking to the COM+ server, kerberos authentication failed