Automatic client re-authentication

Do people generally enable automatic re-authentication? I am having issues with re-authentication overnight when users are not logged in to their machines. They come in the next morning to find their machine authenticated but unauthorized. I am running in closed mode, so they don't get an IP address at that point. Thanks.

Do you have the pre-auth ACL on the switchport? And is it allowing DNS and DHCP?
DHCP requests are sent prior to ISE coming into play.
Additionally, the DACL has nothing to do with the IP address of the machine, DACL is strictly between switch and ISE. However i do see what you're getting at with the DACL not having the IP of the machine.
If there is no IP, i would start with checking the pre-auth ACL on the switch, and the DACL that is applied to the MAB sessions.

Similar Messages

Project Server 2010 Web services access with Client Certificate Authentication

We switched our SharePoint/Project Server 2010 farm to use client certificate authentication with Active Directory Federation Services (AD FS) 2.0, which is working without issue. We have some administrative Project Server Interface (PSI)
web service applications that no longer connect to server with the new authentication configuration. Our custom applications are using the WCF interface to access the public web services.
Please let us know if it is possible to authenticate with AD FS 2.0 and then call
Project Server web services. Any help or coding examples would be greatly appreciated.

what is the error occurred when the custom PSI app connects?
can you upload the ULS logs here for research?
What is the user account format you specified in the code for authentication?
For proper authorization, the “user logon account” in PWA for the user needs to be changed from domain\username to the claims token (e.g.
'I:0#.w|mybusinessdomain\ewmccarty').
It requires you to manually call the UpnLogon method of
“Claims to Windows Token Service”. if (Thread.CurrentPrincipal.Identity is ClaimsIdentity)
{ var identity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity; }
if (Thread.CurrentPrincipal.Identity is ClaimsIdentity)
var identity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity;
Than you need to extract UPN-Claim from the identity.
Upload the verbose log if possible.
Did you see this?
http://msdn.microsoft.com/en-us/library/ff181538(v=office.14).aspx
Cheers. Happy troubleshooting !!! Sriram E - MSFT Enterprise Project Management

Client certificate authentication with custom authorization for J2EE roles?

We have a Java application deployed on Sun Java Web Server 7.0u2 where we would like to secure it with client certificates, and a custom mapping of subject DNs onto J2EE roles (e.g., "visitor", "registered-user", "admin"). If we our web.xml includes:
<login-config>
 <auth-method>CLIENT-CERT</auth-method>
 <realm-name>certificate</realm-name>
<login-config>that will enforce that only users with valid client certs can access our app, but I don't see any hook for mapping different roles. Is there one? Can anyone point to documentation, or an example?
On the other hand, if we wanted to create a custom realm, the only documentation I have found is the sample JDBCRealm, which includes extending IASPasswordLoginModule. In our case, we wouldn't want to prompt for a password, we would want to examine the client certificate, so we would want to extend some base class higher up the hierarchy. I'm not sure whether I can provide any class that implements javax.security.auth.spi.LoginModule, or whether the WebServer requires it to implement or extend something more specific. It would be ideal if there were an IASCertificateLoginModule that handled the certificate authentication, and allowed me to access the subject DN info from the certificate (e.g., thru a javax.security.auth.Subject) and cache group info to support a specialized IASRealm::getGroupNames(string user) method for authorization. In a case like that, I'm not sure whether the web.xml should be:
<login-config>
 <auth-method>CLIENT-CERT</auth-method>
 <realm-name>MyRealm</realm-name>
<login-config>or:
<login-config>
 <auth-method>MyRealm</auth-method>
<login-config>Anybody done anything like this before?
--Thanks

We have JDBCRealm.java and JDBCLoginModule.java in <ws-install-dir>/samples/java/webapps/security/jdbcrealm/src/samples/security/jdbcrealm. I think we need to tweak it to suite our needs :
$cat JDBCRealm.java
* JDBCRealm for supporting RDBMS authentication.
* This login module provides a sample implementation of a custom realm.
* You may use this sample as a template for creating alternate custom
* authentication realm implementations to suit your applications needs.
* In order to plug in a realm into the server you need to
* implement both a login module (see JDBCLoginModule for an example)
* which performs the authentication and a realm (as shown by this
* class) which is used to manage other realm operations.
* A custom realm should implement the following methods:
* <ul>
* <li>init(props)
* <li>getAuthType()
* <li>getGroupNames(username)
* </ul>
* IASRealm and other classes and fields referenced in the sample
* code should be treated as opaque undocumented interfaces.
final public class JDBCRealm extends IASRealm
 protected void init(Properties props)
 throws BadRealmException, NoSuchRealmException
 public java.util.Enumeration getGroupNames (String username)
 throws InvalidOperationException, NoSuchUserException
 public void setGroupNames(String username, String[] groups)
}and
$cat JDBCLoginModule.java
* JDBCRealm login module.
* This login module provides a sample implementation of a custom realm.
* You may use this sample as a template for creating alternate custom
* authentication realm implementations to suit your applications needs.
* In order to plug in a realm into the server you need to implement
* both a login module (as shown by this class) which performs the
* authentication and a realm (see JDBCRealm for an example) which is used
* to manage other realm operations.
* The PasswordLoginModule class is a JAAS LoginModule and must be
* extended by this class. PasswordLoginModule provides internal
* implementations for all the LoginModule methods (such as login(),
* commit()). This class should not override these methods.
* This class is only required to implement the authenticate() method as
* shown below. The following rules need to be followed in the implementation
* of this method:
* <ul>
* <li>Your code should obtain the user and password to authenticate from
* _username and _password fields, respectively.
* <li>The authenticate method must finish with this call:
* return commitAuthentication(_username, _password, _currentRealm,
* grpList);
* <li>The grpList parameter is a String[] which can optionally be
* populated to contain the list of groups this user belongs to
* </ul>
* The PasswordLoginModule, AuthenticationStatus and other classes and
* fields referenced in the sample code should be treated as opaque
* undocumented interfaces.
* Sample setting in server.xml for JDBCLoginModule
* <pre>
* <auth-realm name="jdbc" classname="samples.security.jdbcrealm.JDBCRealm">
* <property name="dbdrivername" value="com.pointbase.jdbc.jdbcUniversalDriver"/>
* <property name="jaas-context" value="jdbcRealm"/>
* </auth-realm>
* </pre>
public class JDBCLoginModule extends PasswordLoginModule
 protected AuthenticationStatus authenticate()
 throws LoginException
 private String[] authenticate(String username,String passwd)
 private Connection getConnection() throws SQLException
}One more article [http://developers.sun.com/appserver/reference/techart/as8_authentication/]
You can try to extend "com/iplanet/ias/security/auth/realm/certificate/CertificateRealm.java"
[http://fisheye5.cenqua.com/browse/glassfish/appserv-core/src/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java?r=SJSAS_9_0]
$cat CertificateRealm.java
package com.iplanet.ias.security.auth.realm.certificate;
* Realm wrapper for supporting certificate authentication.
* The certificate realm provides the security-service functionality
* needed to process a client-cert authentication. Since the SSL processing,
* and client certificate verification is done by NSS, no authentication
* is actually done by this realm. It only serves the purpose of being
* registered as the certificate handler realm and to service group
* membership requests during web container role checks.
* There is no JAAS LoginModule corresponding to the certificate
* realm. The purpose of a JAAS LoginModule is to implement the actual
* authentication processing, which for the case of this certificate
* realm is already done by the time execution gets to Java.
* The certificate realm needs the following properties in its
* configuration: None.
* The following optional attributes can also be specified:
* <ul>
* <li>assign-groups - A comma-separated list of group names which
* will be assigned to all users who present a cryptographically
* valid certificate. Since groups are otherwise not supported
* by the cert realm, this allows grouping cert users
* for convenience.
* </ul>
public class CertificateRealm extends IASRealm
 protected void init(Properties props)
 * Returns the name of all the groups that this user belongs to.
 * @param username Name of the user in this realm whose group listing
 * is needed.
 * @return Enumeration of group names (strings).
 * @exception InvalidOperationException thrown if the realm does not
 * support this operation - e.g. Certificate realm does not support
 * this operation.
 public Enumeration getGroupNames(String username)
 throws NoSuchUserException, InvalidOperationException
 * Complete authentication of certificate user.
 * As noted, the certificate realm does not do the actual
 * authentication (signature and cert chain validation) for
 * the user certificate, this is done earlier in NSS. This default
 * implementation does nothing. The call has been preserved from S1AS
 * as a placeholder for potential subclasses which may take some
 * action.
 * @param certs The array of certificates provided in the request.
 public void authenticate(X509Certificate certs[])
 throws LoginException
 // Set up SecurityContext, but that is not applicable to S1WS..
}Edited by: mv on Apr 24, 2009 7:04 AM

SOAP -Client Certificate Authentication in Receiver SOAP Adapter

Dear All,
We are working on the below scenario
SAP R/3 System -> XI/PI -> Proxy -> Customer
In this, SAP R/3 System sends a IDOC and XI should give that XML Payload of IDOC to Customer.
Cusomer gave us the WSDL file and also a Certificate for authentication.
Mapping - we are using XSLT mapping to send that XML payload as we need to capture the whole XML payload of IDOC into 1 field at the target end ( This was given in the WSDL).
Now, how can we achieve this Client Certificate authentication in the SOAP Receiver Adapter when we have Proxy server in between PI/XI and Customer system.
Require your inputs on Client Certificate authentication and Proxy server configuration.
Regards,
Srini

Hi
Look this blog
How to use Client Authentication with SOAP Adapter
http://help.sap.com/saphelp_nw04/helpdata/en/14/ef2940cbf2195de10000000a1550b0/content.htm
Also refer to "SAP Security Guide XI" at service market place.
ABAP Proxy configuration
How do you activate ABAP Proxies?

How to use CLIENT-CERT authentication?

Hi,
I would like to know how to use client authentication.
I used a web application with CLIENT-CERT authentication.
And I accessed to the application from browser, then I had the following error
message:
Incorrect or missing client certificate.
I used OpenSSL to generate keys.
Could you tell me the information of the setting?
Especially, I don't know theentry of CertAuthenticator.
Could you tell me?
Regards,
Kuniaki Hagiwara - HP Japan

Thank you for your response.
Yes we have added the client certificate file (.pfx) in the Firefox browser Certificate manager / Store. It's also showing the certificate in the View Certificate window. We could not resolve it yet.

CLIENT-CERT authentication in WL7

Hi,
I'm trying to enforce two-way authentication for clients (java applications) accessing
a web service running on WL7.
Web service is configured to accept requests over https only. With BASIC authentication
it works. When I
switch it to use CLIENT-CERT authentication I cannot connect to the web service.
I've set the
"javax.net.debug" directive to "ssl" and noticed that during the handshake procedure
the server doesn't
produce client certificate request. May it be the cause of the problem? If so,
how can I make the server to
generate client cert request?

Exactly, it was the reason. Thanks.
Marcin
On 14 Nov 2003 10:29:39 -0700, Pavel <[email protected]> wrote:
>
You must have been accessing the server over one-way SSL. Make sure the
two-way
ssl server attribute is set to: Client Certificate Enforced, or Client
Certificate
Requested But Not Enforced.
This should be all that is needed to make the server send the
certificate request.
With Client Certificate Enforced option you should be getting ssl
handshake failure
unless the client sends its certificate.
Pavel.
yazzva <[email protected]> wrote:
Yes, I have. If I had not done it, I couldn't have accessed the service
via https using basic authentication, and of course ssl debugging
information and server configuration show that ssl is configured
properly.
The problem is that WL7 doesn't generate client cert request. Thanks
for
an attempt to help.
Have you configured the server for two way ssl?
See
http://e-docs.bea.com/wls/docs70/security/SSL_client.html#1029705
http://e-docs.bea.com/wls/docs70/secmanage/ssl.html#1168174
for information on this.
Pavel.
"yazzva" <[email protected]> wrote:
Hi,
I'm trying to enforce two-way authentication for clients (java
applications)
accessing
a web service running on WL7.
Web service is configured to accept requests over https only. With
BASIC
authentication
it works. When I
switch it to use CLIENT-CERT authentication I cannot connect to theweb
service.
I've set the
"javax.net.debug" directive to "ssl" and noticed that during the
handshake
procedure
the server doesn't
produce client certificate request. May it be the cause of the
problem?
If so,
how can I make the server to
generate client cert request?--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

ABAP client Proxy authentication required

Hallo, my problem is about ABAP client Proxy authentication.
Scenario:
Our Dev. BW MWDCLNT600 queries forward a (RetailPro) database (JDBC Receiver C.Channel), by Dev. XI , in order to "drive" data extraction (realized, backward, from RetailPro to BW).
Forward communication from BW uses a call on ABAP Client Proxy technology (I mean, a BW class implements an XI outbound Message Interface).
Problem:
Something changed, we don't know what or where, and since last week everytime you execute the report (F8) you are prompted for an authentication popup.
Official manual guide is: (ABAP Proxy Generation)
http://help.sap.com/saphelp_nw04/helpdata/en/ba/f21a403233dd5fe10000000a155106/frameset.htm
in which you have to manage the 2 properties for credential supplying:
com.sap.aii.applicationsystem.serviceuser.name
com.sap.aii.applicationsystem.serviceuser.pwd
in order to "drive" authentication to Integration Engine.
In our scenario, ABAP report ZRTP_FLOW_CONTROL drives data extraction query, by a call to execute method
of class: ZCO_MI_FLOW_CONTROL_OB
which implements Outbound MI: MI_Flow_Control_OB (...all in SPROXY).
In SXMB_ADM, XI IEngine URL is correct...
In Exchange Profile, the 2 properties (see above) are correctly maintained (user: XIAPPLUSER, and password is OK)
Any suggestion?
Thanks all in advance!
Gianluca

Hi
I would like to suggest you to change the password in http destination (sm59) configured to comunicate with XI and put another one using UPPER case only. Another thing to check is tx SLDAPICUST. There is a problem in this transaction (I think it is a problem, maybe it's a feature , you need to use password with UPPER there to, and you need to double save the data there (change something, click save, change another thing, click save, and will work, otherwise not). Check tx SLDCHECK to see if connection with SLD and Integration Directory are ok.
Regards.
Roberti

Client Certificate Authentication not working in OSB 11g

Hi All,
I am currently having an issue with getting a 2 way SSL handshake to work in a production environment.
We have the set up working and fully functional in a Test environment, however when we have deployed the code and made the same config changes in the Production environment, it does nto work when calling the API (the result being as if we were not presenting the client cert to the API).
All relevant configuration on Weblogic and OSB was performed (Keystore creation / Security Realm - Service Key Provider / Service Key Providers etc) and I believe to be right.
We can test the keystore using SOAPUI and we get a valid response from the live API.
We can see the relevant aliases in OSB Service Key Provider so I know that the Security Realm / Identity settings are correct on the Weblogic Server.
The Test and Production Weblogic properties all look the same for Keystores / Secuirty Realms / SSL etc (expect with live keystores etc).
As we can see the aliases in OSB when setting up the Service Key Provider, it should just be a matter of setting the 'Authentication' of the business service making the call to 'Client Certificate' and this has also been done.
Though we always get an authentication error and code, that matched what we would get if we turn off the client cert authentication on the business service in the test environment (i.e not sending the certificate with the request).
What I really want to know is how can I find out for sure whether we are sending this certificate with our request or not? As I am struggling to find a way to log these details.
Any input appreciated.
Jamie

This is issue has now been resolved.
It was an environment specific issue rather than anything wrong with the actual code.

Client Cert Authentication

Is there any documentation that explain how to set up iAS 6.0 SP3 to use
Client Cert Authentication?
Thanks in advance,
Jose.

Hi,
I am not able to understand what "client cert authentication" means can
you please elaborate more on this. If this means authorization process by
any chance, then iAS uses LDAP that is bundled along with iAS to
authenticate. There is no other means to validate the users.
Regards
Raj
Jose Raya wrote:
Is there any documentation that explain how to set up iAS 6.0 SP3 to use
Client Cert Authentication?
Thanks in advance,
Jose.

Having problem with client side Authentication.

Hi,
I am haveing a problem enabling client side authentication with SSL on
weblogic 5.1.
I have set up the .properties files as explained, however it appears
my client is not sending a certificate back to the server. The same
client however works perfectly (using the same keystore file) with a
sample ClassFileSErver webserver from the jsse distribution. (the
client is a very slightly modified version of
SSLSocketClientWithClientAuth sample that comes with Jsse)
Below I've included a section of the debug dump from the interactions.
The only other difference I can see is the cipher suites offered by
the servers.
Weblogic offers type 0 or 9, and agrees on type 9
(SSL_RSA_WITH_DES_CBC_SHA), whereas ClassFileServer offer type 0 or 5
and settles on type 5 (SSL_RSA_WITH_RC4_128_SHA).
I am using the same keystore for both examples. Both servers request
an RSA client cert.... I'm out of ideas.
Any help would be greatfully received.
Cheers,
Keith
Debug dump information
=====================================
1/Weblogic server.
*** CertificateRequest
Cert Types: RSA,
Cert Authorities:
<CN=K H, OU=itsmobile, O=itsmobile, L=Dublin, ST=Dublin, C=ie>
<[email protected], CN=Demo Certificate Authority,
OU=Security, O=BEA WebLogic, L=San Francisco, ST=California, C=US>
<CN=Thawte Test CA Root, OU=TEST TEST TEST, O=Thawte Certification,
ST=FOR TESTING PURPOSES ONLY, C=ZA>
[read] MD5 and SHA1 hashes: len = 427
0000: 0D 00 01 A7 01 01 01 A3 00 67 30 65 31 0B 30 09
.........g0e1.0.
0010: 06 03 55 04 06 13 02 69 65 31 0F 30 0D 06 03 55
..U....ie1.0...U
0020: 04 08 13 06 44 75 62 6C 69 6E 31 0F 30 0D 06 03
....Dublin1.0...
0030: 55 04 07 13 06 44 75 62 6C 69 6E 31 12 30 10 06
U....Dublin1.0..
0040: 03 55 04 0A 13 09 69 74 73 6D 6F 62 69 6C 65 31
.U....itsmobile1
0050: 12 30 10 06 03 55 04 0B 13 09 69 74 73 6D 6F 62
.0...U....itsmob
0060: 69 6C 65 31 0C 30 0A 06 03 55 04 03 13 03 4B 20
ile1.0...U....K
0070: 48 00 AC 30 81 A9 31 0B 30 09 06 03 55 04 06 13
H..0..1.0...U...
0080: 02 55 53 31 13 30 11 06 03 55 04 08 13 0A 43 61
.US1.0...U....Ca
0090: 6C 69 66 6F 72 6E 69 61 31 16 30 14 06 03 55 04
lifornia1.0...U.
00A0: 07 13 0D 53 61 6E 20 46 72 61 6E 63 69 73 63 6F ...San
Francisco
00B0: 31 15 30 13 06 03 55 04 0A 13 0C 42 45 41 20 57
1.0...U....BEA W
00C0: 65 62 4C 6F 67 69 63 31 11 30 0F 06 03 55 04 0B
ebLogic1.0...U..
00D0: 13 08 53 65 63 75 72 69 74 79 31 23 30 21 06 03
..Security1#0!..
00E0: 55 04 03 13 1A 44 65 6D 6F 20 43 65 72 74 69 66 U....Demo
Certif
00F0: 69 63 61 74 65 20 41 75 74 68 6F 72 69 74 79 31 icate
Authority1
0100: 1E 30 1C 06 09 2A 86 48 86 F7 0D 01 09 01 16 0F
.0...*.H........
0110: 73 75 70 70 6F 72 74 40 62 65 61 2E 63 6F 6D 00
[email protected].
0120: 8A 30 81 87 31 0B 30 09 06 03 55 04 06 13 02 5A
.0..1.0...U....Z
0130: 41 31 22 30 20 06 03 55 04 08 13 19 46 4F 52 20 A1"0
..U....FOR
0140: 54 45 53 54 49 4E 47 20 50 55 52 50 4F 53 45 53 TESTING
PURPOSES
0150: 20 4F 4E 4C 59 31 1D 30 1B 06 03 55 04 0A 13 14
ONLY1.0...U....
0160: 54 68 61 77 74 65 20 43 65 72 74 69 66 69 63 61 Thawte
Certifica
0170: 74 69 6F 6E 31 17 30 15 06 03 55 04 0B 13 0E 54
tion1.0...U....T
0180: 45 53 54 20 54 45 53 54 20 54 45 53 54 31 1C 30 EST TEST
TEST1.0
0190: 1A 06 03 55 04 03 13 13 54 68 61 77 74 65 20 54
...U....Thawte T
01A0: 65 73 74 20 43 41 20 52 6F 6F 74 est CA Root
main, READ: SSL v3.0 Handshake, length = 4
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
main, SEND SSL v3.0 ALERT: warning, description = no_certificate
main, WRITE: SSL v3.0 Alert, length = 2
And below is a sample when I used the ClassFileServer.
This time the client (same src) returned a certificate.
2/ClassFileSErver (from Sun Jsse distribution)
*** CertificateRequest
Cert Types: DSS, RSA,
Cert Authorities:
<CN=K H, OU=itsmobile, O=itsmobile, L=Dublin, ST=Dublin, C=ie>
[read] MD5 and SHA1 hashes: len = 114
0000: 0D 00 00 6E 02 02 01 00 69 00 67 30 65 31 0B 30
...n....i.g0e1.0
0010: 09 06 03 55 04 06 13 02 69 65 31 0F 30 0D 06 03
...U....ie1.0...
0020: 55 04 08 13 06 44 75 62 6C 69 6E 31 0F 30 0D 06
U....Dublin1.0..
0030: 03 55 04 07 13 06 44 75 62 6C 69 6E 31 12 30 10
.U....Dublin1.0.
0040: 06 03 55 04 0A 13 09 69 74 73 6D 6F 62 69 6C 65
..U....itsmobile
0050: 31 12 30 10 06 03 55 04 0B 13 09 69 74 73 6D 6F
1.0...U....itsmo
0060: 62 69 6C 65 31 0C 30 0A 06 03 55 04 03 13 03 4B
bile1.0...U....K
0070: 20 48 H
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
matching client alias : rsakey
*** Certificate chain

Matt,
Did you read this article:
https://wiki.sdn.sap.com/wiki/display/BSP/Using%20Proxies
This explains how to properly setup the HTTPURLLOC table.
In your case you should have entries that look something like this:
40 HTTP * <internal host name> <https port>
50 HTTPS * <external host name> <https port>
In addition you need to run the report to determine if the proxy configuration is setup properly. The URL should be run with the
https://<externalhostname>/sap/bc/bsp/sap/system_test/test_proxy.htm
Take care,
Stephen

Exclude Servers for Automatic Client Deployment/Upgrade

We have 2012 SP1 and are planning the move to R2. We have automatic client upgrade enabled in the site settings. Is there a way to exclude Server OS client upgrades while this feature is enabled? In my reading there are times when the client
upgrade will reboot the systems at will due to a pre-requisite installing such as a security update.
We cannot have the servers rebooting at will. It will be difficult enough to have workstations do it.
Thank you

No. There is no way of excluding specific systems from the automatic client upgrade. It's all or nothing.
My Blog: http://www.petervanderwoude.nl/
Follow me on twitter: pvanderwoude

Automatic Client Push not working - Site System Servers

Having an issue getting automatic site-wise client push to work when only
having "Configuration Manager site system servers" selected. This was turned on after discovery was enabled and fully executed.
SCCM 2012 R2 CU1, Single Primary Site Server, 2 Management Points (one on primary and second is standalone), with 5 DP's (currently), SQL is standalone.
The site systems are within the IP range boundaries and show as assigned (i.e. site code showing in console of object). The boundaries are in a boundary group with site assignment selected, and a DP added. When I view the object properties I
see its returning the correct IP that does fall withing the IP range boundary.
Nothing in the ccm.log indicating its ever trying to install the client and the ccr and ccrretry folders are empty. I can do a manual client push without issue to a site server object or a discovered desktop/laptop object.
Is there something I may be missing here? And does anyone know the interval in which SCCM should be creating ccr records for discovered objects that don't have a client?

Thanks or the quick replies everyone. To answer Idan's questions, no errors in log or component status and SQL is not clustered.
John, I hope this isn't the case. If it were wouldn't that effectively mean you would not be able to enabled discovery until you are ready to turn on auto client push? And if you did that you would have no way to control the client roll out.
Maybe I am missing something in that equation. I'll test that theory regardless but if that ends up being the case that is alarming! :-)
Jason, thanks for the tip on the potential bug. Was really more so hoping to validate automatic client push rather than actually needing it for my site system servers. So if it is the issue you reference above hopefully its just contained to
the site system servers. Would be nice to be able to select automatic client push to just a collection of devices prior to turning it on for site wide deployment.
I guess I could always just turn off discovery temporarily and delete all but some test clients, enable client push for workstations, then once validated, turn it back off and re-enable discovery. (wouldn't turn push back on until most clients are
deployed on the roll out schedule)

Unable to achieve client certificate authentication

I am trying to do mutual certificate authentication (client/server authentication), and getting following error.
Anybody has any clue?
SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
My code is below.
import com.sun.net.ssl.HttpsURLConnection;
import java.security.cert.*;
import javax.net.ssl.*;
import java.security.*;
import java.net.URL;
import java.io.*;
import java.util.Enumeration;
public class ClientCert {
private static SSLSocketFactory getSocketFactory() {
SSLSocketFactory theFactory = null;
try {
// set up key manager to do server authentication
SSLContext theContext;
KeyManagerFactory theKeyManagerFactory;
KeyStore theKeyStore;
char[] thePassword = "goldy123".toCharArray();
theContext = SSLContext.getInstance("TLS");
theKeyManagerFactory = KeyManagerFactory.getInstance("SunX509");
theKeyStore = KeyStore.getInstance("JKS");
theKeyStore.load(new FileInputStream("c:/castore"), thePassword);
//java.security.cert.Certificate certi[] = theKeyStore.getCertificateChain("ca");
// System.out.println("Certificate "+certi.length);
theKeyManagerFactory.init(theKeyStore, thePassword);
KeyManager managers[] = theKeyManagerFactory.getKeyManagers();
theContext.init(managers, null, null);
theFactory = theContext.getSocketFactory();
return theFactory;
} catch (Exception e) {
System.err.println("Failed to create a server socket factory...");
e.printStackTrace();
return null;
public static void main(String[] args) {
try {
System.setProperty("java.protocol.handler.pkgs","com.sun.net.ssl.internal.www.protocol");
java.security.Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
com.sun.net.ssl.HostnameVerifier hv=new com.sun.net.ssl.HostnameVerifier() {
public boolean verify(String urlHostname, String certHostname) {
return true;
HttpsURLConnection.setDefaultHostnameVerifier(hv);
URL mioUrl = new URL("https://viveksharma:9090/LoginPage.do?userName=root&password=password");
//URL mioUrl = new URL("https://www.verisign.com");
//SSLSocketFactory factory = getFactorySSLFromCert(mioCertFile ,mioCertPswd );
//HttpsURLConnection.setDefaultSSLSocketFactory(factory);
//System.setProperty("javax.net.ssl.keyStore","C:/castore");
//System.setProperty("javax.net.ssl.keyStorePassword","goldy123");
System.setProperty("javax.net.ssl.trustStore","C:/vivekstore");
System.setProperty("javax.net.ssl.trustStorePassword","goldy123");
HttpsURLConnection.setDefaultSSLSocketFactory(getSocketFactory());
HttpsURLConnection urlConn = (HttpsURLConnection)mioUrl.openConnection();
urlConn.connect();
//urlConn.setDoInput(true);
// urlConn.setUseCaches(false);
javax.security.cert.X509Certificate ch[] = urlConn.getServerCertificateChain();
System.out.println(ch[0]);
InputStreamReader streamIn = new InputStreamReader(urlConn.getInputStream());
BufferedReader in = new BufferedReader(streamIn);
String inputLine;
while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);
in.close();
} catch (Exception e) {
e.printStackTrace();

Hello guys!
I've had this problem twice (once with Tomcat server and once with OC4J -- Oracle 9iAS) and was able to resolve it.
First of, make sure that the certificate your client is passing is valid (I always use JKS format... i think its a must when using JSSE) and is in your server's truststore (and that you specify which truststore file for your server to look at in your config file).
Secondly, also import the root CA of your client cerficate (if it isn't there yet) to the cacert file in $JAVA_HOME/jre/lib/security.
Hope this helps.

Question on client side authentication

Does anyone have recommendation for a good way to do client side
authentication in a java application and pass it through to the application
server for RMI calls? I can use JAAS to authenticate the user on the client
side but how do I get the user principal to pass through to the weblogic
server as part of the RMI call.
Kent

You can check out both JAAS and JNDI authentication for weblogic in this link:
http://edocs.bea.com/wls/docs61/security/prog.html#1022997
"Kent Mitchell" <[email protected]> wrote:
Does anyone have recommendation for a good way to do client side
authentication in a java application and pass it through to the application
server for RMI calls? I can use JAAS to authenticate the user on the
client
side but how do I get the user principal to pass through to the weblogic
server as part of the RMI call.
Kent

Automatic Client Push

We recently migrated from SCCM 2007 to SCCM 2012 R2. I did the migration by manually pushing out clients, and now that a majority are migrated, I enabled Automatic Client Push. However, resources that were already discovered without the client
installed aren't receiving the client. Checking CCM.log on the primary site server, I don't see SCCM even attempting to push the client.
Any ideas?

Can you post a portion of the ccm.log?
I apparently can't post much of it. The workstations that are failing are ones I pushed to manually the day prior. This is from the point of enabling automatic client push, and a bit afterwards:
Waking up for site control file directory change notification $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:33.896+360><thread=17076 (0x42B4)>
The Site Control File has changed, parameters will be reread. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:33.965+360><thread=17076 (0x42B4)>
Updating Site Parameters $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:33.984+360><thread=17076 (0x42B4)>
~MP Ports: 80 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:33.998+360><thread=17076 (0x42B4)>
~IISPreferedPort: 80 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.012+360><thread=17076 (0x42B4)>
~MP SSL Ports: 443 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.025+360><thread=17076 (0x42B4)>
~IISSSLPreferedPort: 443 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.040+360><thread=17076 (0x42B4)>
~Default MP: SCCM.Domain.com $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.053+360><thread=17076 (0x42B4)>
~Default MP Type: 1 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.067+360><thread=17076 (0x42B4)>
~Default MP: [None] $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.081+360><thread=17076 (0x42B4)>
~Certificate Selection Criteria: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.094+360><thread=17076 (0x42B4)>
~Certificate Store: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.107+360><thread=17076 (0x42B4)>
~SSL State: 224 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.120+360><thread=17076 (0x42B4)>
~Select First Certificate: 1 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.134+360><thread=17076 (0x42B4)>
~Certificate Issuers: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.159+360><thread=17076 (0x42B4)>
Checking configuration information for server: SCCM.Domain.COM.~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.174+360><thread=17076 (0x42B4)>
~No Fallback Status Point installed on the Site $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.187+360><thread=17076 (0x42B4)>
~Install on DC: True $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.200+360><thread=17076 (0x42B4)>
~Option for installing using IP address: 0 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.214+360><thread=17076 (0x42B4)>
Retrieving properties from the site control file. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.226+360><thread=17076 (0x42B4)>
~Advanced Client Command Line: SMSSITECODE=STE $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.239+360><thread=17076 (0x42B4)>
Ignoring unrecognized property "Advanced Client Command Line Default" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.253+360><thread=17076 (0x42B4)>
~Security Mode Option - CCR buffering disabled. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.266+360><thread=17076 (0x42B4)>
~Default Client Type: -1 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.279+360><thread=17076 (0x42B4)>
Sleeping for 981 seconds... $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 18:57:34.300+360><thread=17076 (0x42B4)>
CCM Shutting down (12)~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:11:12.799+360><thread=10212 (0x27E4)>
No request returned from queue $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:11:12.836+360><thread=10212 (0x27E4)>
CCM Shutting down... (4)~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:11:12.850+360><thread=17076 (0x42B4)>
CCM Main thread is exiting...~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:11:12.908+360><thread=17076 (0x42B4)>
SMS_EXECUTIVE started SMS_CLIENT_CONFIG_MANAGER as thread ID 2664 (0xA68). $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.269+360><thread=16000 (0x3E80)>
************** Client Config Manager main thread starting ************** $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.294+360><thread=2664 (0xA68)>
This site: "STE". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.308+360><thread=2664 (0xA68)>
This site type: "1". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.324+360><thread=2664 (0xA68)>
This machine: "SCCM.Domain.com". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.338+360><thread=2664 (0xA68)>
The Site Control File has changed, parameters will be reread. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.498+360><thread=2664 (0xA68)>
Updating Site Parameters $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.570+360><thread=2664 (0xA68)>
~MP Ports: 80 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.615+360><thread=2664 (0xA68)>
~IISPreferedPort: 80 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.630+360><thread=2664 (0xA68)>
~MP SSL Ports: 443 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.644+360><thread=2664 (0xA68)>
~IISSSLPreferedPort: 443 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.658+360><thread=2664 (0xA68)>
~Default MP: SCCM.Domain.com $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.680+360><thread=2664 (0xA68)>
~Default MP Type: 1 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.693+360><thread=2664 (0xA68)>
~Default MP: [None] $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.705+360><thread=2664 (0xA68)>
~Certificate Selection Criteria: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.718+360><thread=2664 (0xA68)>
~Certificate Store: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.732+360><thread=2664 (0xA68)>
~SSL State: 224 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.745+360><thread=2664 (0xA68)>
~Select First Certificate: 1 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.758+360><thread=2664 (0xA68)>
~Certificate Issuers: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.774+360><thread=2664 (0xA68)>
Checking configuration information for server: SCCM.Domain.COM.~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.788+360><thread=2664 (0xA68)>
~No Fallback Status Point installed on the Site $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.801+360><thread=2664 (0xA68)>
~Install on DC: True $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.819+360><thread=2664 (0xA68)>
~Option for installing using IP address: 0 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.845+360><thread=2664 (0xA68)>
Retrieving properties from the site control file. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.864+360><thread=2664 (0xA68)>
~Advanced Client Command Line: SMSSITECODE=STE $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.878+360><thread=2664 (0xA68)>
Ignoring unrecognized property "Advanced Client Command Line Default" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.893+360><thread=2664 (0xA68)>
~Security Mode Option - CCR buffering disabled. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.914+360><thread=2664 (0xA68)>
~Default Client Type: -1 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.927+360><thread=2664 (0xA68)>
Confirming all required files are available on the site server~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.942+360><thread=2664 (0xA68)>
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.965+360><thread=2664 (0xA68)>
Site Server Name "\\SCCM.Domain.com" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:56.980+360><thread=2664 (0xA68)>
Site Code "STE" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.020+360><thread=2664 (0xA68)>
CCM Account 1 "Domain\clientdeploy" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.054+360><thread=2664 (0xA68)>
CCM Account 2 "Domain2\clientdeploy" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.067+360><thread=2664 (0xA68)>
CCM Account 3 "<end of list>" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.081+360><thread=2664 (0xA68)>
Max CCR Processing Threads 10 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.095+360><thread=2664 (0xA68)>
CCR Processing Thread Timeout 600000 ms $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.108+360><thread=2664 (0xA68)>
Sitewide Travel Mode Switch USE CLIENT SETTING $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.131+360><thread=2664 (0xA68)>
Days Between Account Cleanups 30 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.143+360><thread=2664 (0xA68)>
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.156+360><thread=2664 (0xA68)>
Parameters for queue: "Incoming" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.168+360><thread=2664 (0xA68)>
Inbox Path "E:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.181+360><thread=2664
(0xA68)>
Read Queue Every DIR CHANGE NOTIFICATION $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.193+360><thread=2664 (0xA68)>
Retry CCR For 168 Hours $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.206+360><thread=2664 (0xA68)>
Report Error After ERROR REPORTING OFF $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.219+360><thread=2664 (0xA68)>
Warn when Queue Exceeds 100 CCRs $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.246+360><thread=2664 (0xA68)>
Delay Between CCRs 100 Millisec $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.259+360><thread=2664 (0xA68)>
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.271+360><thread=2664 (0xA68)>
Parameters for queue: "Retry" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.284+360><thread=2664 (0xA68)>
Inbox Path "E:\Program Files\Microsoft Configuration Manager\inboxes\ccrretry.box" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.297+360><thread=2664
(0xA68)>
Read Queue Every 60 Minutes $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.310+360><thread=2664 (0xA68)>
Retry CCR For 168 Hours $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.323+360><thread=2664 (0xA68)>
Report Error After 24 Hours $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.336+360><thread=2664 (0xA68)>
Warn when Queue Exceeds 150 CCRs $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.349+360><thread=2664 (0xA68)>
Delay Between CCRs 100 Millisec $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.361+360><thread=2664 (0xA68)>
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.374+360><thread=2664 (0xA68)>
Parameters for queue: "Processing" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.387+360><thread=2664 (0xA68)>
Inbox Path "E:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box\InProc" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.389+360><thread=2664
(0xA68)>
Read Queue Every DIR CHANGE NOTIFICATION $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.415+360><thread=2664 (0xA68)>
Retry CCR For CCR DOESN'T EXPIRE $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.428+360><thread=2664 (0xA68)>
Report Error After ERROR REPORTING OFF $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.440+360><thread=2664 (0xA68)>
Warn when Queue Exceeds 150 CCRs $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.453+360><thread=2664 (0xA68)>
Delay Between CCRs 0 Millisec $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.466+360><thread=2664 (0xA68)>
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.478+360><thread=2664 (0xA68)>
Moving CCRs from processing queue to incoming queue~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.491+360><thread=2664 (0xA68)>
Started Incoming Queue Thread, ThreadId = 2488 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.505+360><thread=2664 (0xA68)>
Started Retry Queue Thread, ThreadId = 1548 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.518+360><thread=2664 (0xA68)>
Sleeping for 300 seconds... $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.531+360><thread=2664 (0xA68)>
THREAD_ProcessQ starting, Input Queue ID is 0. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.551+360><thread=9352 (0x2488)>
Queue Name is "Incoming". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.632+360><thread=9352 (0x2488)>
Queue Directory is "E:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.697+360><thread=9352 (0x2488)>
Sleeping for 300 seconds before processing requests on queue Incoming... $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.711+360><thread=9352 (0x2488)>
THREAD_ProcessQ starting, Input Queue ID is 1. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.531+360><thread=5448 (0x1548)>
Queue Name is "Retry". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.773+360><thread=5448 (0x1548)>
Queue Directory is "E:\Program Files\Microsoft Configuration Manager\inboxes\ccrretry.box". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.785+360><thread=5448 (0x1548)>
Sleeping for 480 seconds before processing requests on queue Retry... $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:13:57.804+360><thread=5448 (0x1548)>
~Waking up for site control file directory change notification $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.148+360><thread=2664 (0xA68)>
The Site Control File has not changed since the last parameter update. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.170+360><thread=2664 (0xA68)>
Updating Site Parameters $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.183+360><thread=2664 (0xA68)>
~MP Ports: 80 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.200+360><thread=2664 (0xA68)>
~IISPreferedPort: 80 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.247+360><thread=2664 (0xA68)>
~MP SSL Ports: 443 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.260+360><thread=2664 (0xA68)>
~IISSSLPreferedPort: 443 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.279+360><thread=2664 (0xA68)>
~Default MP: SCCM.Domain.com $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.298+360><thread=2664 (0xA68)>
~Default MP Type: 1 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.311+360><thread=2664 (0xA68)>
~Default MP: [None] $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.324+360><thread=2664 (0xA68)>
~Certificate Selection Criteria: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.337+360><thread=2664 (0xA68)>
~Certificate Store: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.351+360><thread=2664 (0xA68)>
~SSL State: 224 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.364+360><thread=2664 (0xA68)>
~Select First Certificate: 1 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.379+360><thread=2664 (0xA68)>
~Certificate Issuers: $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.392+360><thread=2664 (0xA68)>
Checking configuration information for server: SCCM.Domain.COM.~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.411+360><thread=2664 (0xA68)>
~No Fallback Status Point installed on the Site $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.494+360><thread=2664 (0xA68)>
~Install on DC: True $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.520+360><thread=2664 (0xA68)>
~Option for installing using IP address: 0 $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.535+360><thread=2664 (0xA68)>
Sleeping for 282 seconds... $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:14:15.557+360><thread=2664 (0xA68)>
CCR count in queue "Incoming" is 0. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:18:57.577+360><thread=2664 (0xA68)>
CCR count in queue "Processing" is 0. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:18:57.590+360><thread=2664 (0xA68)>
Sleeping for 300 seconds... $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:18:57.603+360><thread=2664 (0xA68)>
Getting a new request from queue "Incoming" after 100 millisecond delay. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:18:57.733+360><thread=9352 (0x2488)>
Waiting for change in directory "E:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box" for queue "Incoming", (30 minute backup timeout). $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:18:57.746+360><thread=9352
(0x2488)>
Getting a new request from queue "Retry" after 100 millisecond delay. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:57.827+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_GetPushRequestMachine] 2097152351~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:57.944+360><thread=5448 (0x1548)>
Successfully retrieved information for machine workstation2 from DB $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:57.957+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_GetPushRequestMachineIP] 2097152351~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:57.969+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_GetPushRequestMachineResource] 2097152351~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:57.983+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_GetPushMachineName] 2097152351~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:57.996+360><thread=5448 (0x1548)>
Received request: "2097152351" for machine name: "workstation2" on queue: "Retry". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:58.008+360><thread=5448 (0x1548)>
Stored request "2097152351", machine name "workstation2", in queue "Processing". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:58.021+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_SetPushRequestMachineStatus] 2097152351, 1~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:21:58.036+360><thread=5448 (0x1548)>
----- Started a new CCR processing thread. Thread ID is 0x335c. There are now 1 processing threads $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.061+360><thread=5448 (0x1548)>
Submitted request successfully $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.074+360><thread=5448 (0x1548)>
Getting a new request from queue "Retry" after 100 millisecond delay. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.087+360><thread=5448 (0x1548)>
Found CCR "2097152396.ccr" in queue "Retry". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.099+360><thread=5448 (0x1548)>
======>Begin Processing request: "2097152351", machine name: "workstation2" $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.074+360><thread=13148 (0x335C)>
Execute query exec [sp_IsMPAvailable] N'STE'~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.129+360><thread=13148 (0x335C)>
---> Trying each entry in the SMS Client Remote Installation account list~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.142+360><thread=13148 (0x335C)>
---> Attempting to connect to administrative share '\\workstation2\admin$' using account 'Domain\sccmclientdeploy'~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.155+360><thread=13148 (0x335C)>
Execute query exec [sp_CP_GetPushRequestMachine] 2097152396~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.211+360><thread=5448 (0x1548)>
Successfully retrieved information for machine workstation1 from DB $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.230+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_GetPushRequestMachineIP] 2097152396~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.243+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_GetPushRequestMachineResource] 2097152396~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.256+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_GetPushMachineName] 2097152396~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.269+360><thread=5448 (0x1548)>
Received request: "2097152396" for machine name: "workstation1" on queue: "Retry". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.283+360><thread=5448 (0x1548)>
Stored request "2097152396", machine name "workstation1", in queue "Processing". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.296+360><thread=5448 (0x1548)>
Execute query exec [sp_CP_SetPushRequestMachineStatus] 2097152396, 1~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.312+360><thread=5448 (0x1548)>
---> Connected to administrative share on machine workstation2 using account 'Domain\sccmclientdeploy'~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.213+360><thread=13148 (0x335C)>
---> Attempting to make IPC connection to share <\\workstation2\IPC$> ~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.351+360><thread=13148 (0x335C)>
---> Searching for SMSClientInstall.* under '\\workstation2\admin$\'~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.368+360><thread=13148 (0x335C)>
---> Unable to connect to WMI on remote machine "workstation2", error = 0x80041002. $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.457+360><thread=13148 (0x335C)>
---> Deleting SMS Client Install Lock File '\\workstation2\admin$\SMSClientInstall.STE'~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.470+360><thread=13148 (0x335C)>
Execute query exec [sp_CP_SetLastErrorCode] 2097152351, -2147217406~ $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.491+360><thread=13148 (0x335C)>
Stored request "2097152351", machine name "workstation2", in queue "Retry". $$<SMS_CLIENT_CONFIG_MANAGER><01-08-2015 19:22:00.505+360><thread=13148 (0x335C)>

Automatic client re-authentication

Similar Messages

Maybe you are looking for