I'm trying to use PeopleCode to get a file from a remote FTP server that uses SSL. The GetAttachment command returns error code 8, which indicates a problem connecting or authenticating with the "destination server" (which I'm assuming means "remote server"). I don't think the problem is in my code itself, although I'm not discounting that, but rather in the URL configuration and the security certificate.
First, my PeopleCode is:
&returnCode = GetAttachment(URL.MY_FTP_URL, &fileName, &destinationPath);
If &returnCode = %Attachment_Success Then
[...]
Else
MessageBox(0, "", 0, 0, "Fail: " | &returnCode)
End-If;
I've created the URL definition via PeopleTools > Utilities > Administration > URLs. The URL is pretty straight forward. The URLID is "ftps://[remote server]/". I know this connection requires active mode and SSL, so I've added the properties (in addition to username and password) ACTIVEMODE = Y, and SSLUSAGELEVEL = 3.
Now, here is where I think the problem is. By adding the SSLUSAGELEVEL property, I also need to add the CERTALIAS property and (presumably) set it to the name of the SSL certificate. So I got the certificate, uploaded it and created the definition. I went back to the URL definition, added the CERTALIAS property, but the prompt box for the valid values is empty.
I think my problem now is that I need to perform some other step to get the certificate I created to show up in the CERTALIAS prompt. Is my approach generally in the right direction? Or am I missing something else entirely?
Thanks,
First, confirm that it is working at the operating system level.
I have noticed that GetAttachment does not always copy over the ssl certificate with the proper file system permissions, in Oracle linux, to the app server working directory and because of the incorrect file permissions, the destination server will refuse the connection.
I had to create the key file with the correct file permissions and hardcode the path to this key file, with the correct file permissions, in the URL entry.
Related
I have one issue when trying to connect to the LDAP server through code. It works fine when I use admin tool to connect to it.
it works fine when using this admin tool to connect to it.
it doesn't work when I use this code to connect to it, it says
The server could not be contacted. ---> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
My code:
Using context As DirectoryServices.AccountManagement.PrincipalContext = New DirectoryServices.AccountManagement.PrincipalContext(DirectoryServices.AccountManagement.ContextType.Domain, SingleSignOn.ADDomain, SingleSignOn.ADSecurityGroup, DirectoryServices.AccountManagement.ContextOptions.SecureSocketLayer Or DirectoryServices.AccountManagement.ContextOptions.Negotiate, UserName, Password)
Using foundUser = DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(context, UserName)
Return foundUser IsNot Nothing
End Using
End Using
My question is:
how to set up the code to use version 3?
Thank you in advance for your help/ideas.
Windows needs to trust the SSL certificate, otherwise the connection will fail. Unfortunately the error message doesn't tell you that.
You have a couple options:
Change the certificate being used on the server to a certificate from a trusted root authority. This is the best way to do it, especially if this is a production server.
Tell Windows to trust the self-signed cert. This would have to be done on every computer that will connect. To do this, use the PowerShell script in this answer to download the certificate (change the URL to match your server). This will give you a .cer file. Then follow the instructions here to import it on the computer that you are running this code on. In that article, start at the heading "To start the certificate import process through Microsoft Management Console (MMC)". In step 4, you have the option to import it for the current user only, or for the whole computer (which requires local admin rights).
I'm trying to connect to an admin server in WLST using config and key files. There are no error messages but I am prompted for a username and password. These files were created (by another developer who is long gone[1]) with the storeUserConfig() command. My call to connect looks something like this: connect(userConfigFile=configFile, userKeyFile=keyFile, url='t3://somehost:7031')).
Is there some restriction in using these files, such as it can only be used on the host where created, or it needs access to the domain's boot.properties file?
Note: I'm trying to connect to an admin server on a different host and non-standard port (e.g. not 7001). The server I am running WLST on and the remote host are the same version of Weblogic.
Some of the things I have tried:
verified that these files appear correct, the key file being binary data and the config file having a line for "weblogic.management.username={AES}..." and "weblogic.management.password={AES}...".
verified that there is a server on the specified port by entering a known login and password that is successful
specified the admin server in the connect parameter
turn on debug(true); the only output is <wlst-debug> connect : Will check if userConfig and userKeyFile should be used to connect to the server and another line giving the path to the userConfig file
turn on Python logging in jython with -Dpython.verbose=debug; nothing relevant to decryption operation
Munging the key or the config files generates no error messages and behaviour as above
[1]: These files are still used today by other existing WLST scripts. However, these scripts are so convoluted and deliberately obfuscated that they are very difficult to reverse-engineer how connect() is being called.
You do not need to access to the domain's boot.properties file. You just need to make sure the configFile and keyFile pointing to the right files. FYI, here is one of the commands we are using:connect(userConfigFile='./user.secure',userKeyFile='./key.secure',url='t3://somehost:7001')
Have you check the network connectity that might be having a firewall in between that troubling you, check the traceroute from the script machine to the Remote machine. Recently I have faced simalar issue. once the routing table updated with allow the WL admin server port everything got set.
Hope this could helps you!
I had this problem too. In a script, I exported the Linux variables userConfigFile and userKeyFile. Then I connected by running:
url='t3://localhost:7002'
userConfigFile='$userConfigFile'
userKeyFile='$userKeyFile'
connect(userConfigFile=$userConfigFile, userKeyFile=#userKeyFile, url=url)
That all worked in a script, but would not work interactively. I changed to doing the following:
url='t3://localhost:7002'
userConfigFile='/users/me/weblogic-2014/weblogic-admin-WebLogicConfig.properties'
userKeyFile='/users/me/weblogic-2014/weblogic-admin-WebLogicKey.properties'
connect(userConfigFile=userConfigFile, userKeyFile=userKeyFile, url=url)
And that worked interactively.
I am trying to get our build server (TFS2010) to sign the assemblies for one of our projects.
I have manually imported the pfx (and associated 'chain' certificate) from verisign on the build machine, under/within the context of the build user account. I am using ResovleKeySource as part of the before build where I should be getting the ResolvedThumbprint as an output parameter.
The project file has the SignAssembly property set to true.
When i run this locally (ie build within VS2012), if I add a property to the proj file (ie CertificateThumbprint) with the thumbprint, on my local machine it finds the certificate in the store and signs the assembly.
The same thumbprint value is passed as a parameter to the build process, I can see it's there (using message statements) however, as noted, it never resolves.
Build user is local admin on that machine.
Has anyone encountered anything similar, and have suggestions on how to resolve the issue?
I am not getting errors from the build process (ie such as can't find certificate in store) - I get nothing. No errors, but no resolved thumbprint either.
Ok, so it looks like there may have been a funky (unprinted) character in the thumbprint that was passed as a parameter from TFS to build. I had another developer look at the build definition, got them to modify the thumbprint parm value (yes, the ONLY change made) and, voila, the build starts signing like a champ....
I am trying to ignore the certificate warning on remote desktop connection - the one in the image:
So far I have found that when I check the "don't ask again" checkbox it is generating registry key over here:
HKCU:\Software\Microsoft\Terminal Server Client\Servers
A new record is generated with the name of the server and key name CertHash that contains a value that is specific for a machine. The key is the same for a machine - if I delete it and check the checkbox the same value is again generated. There is a new value in case I recreate the virtual machine so I think it is something machine specific.
Can someone tell me how is this hash generated so I can populate the key from command line? Adding certificate is not an option and the machines will be frequently regenerated so I need an option to ignore this automatically as I need to connect a user to the machine and run some programs in it.
I know this is an old question. But this may help someone who is looking for the same solution.
Method 1
You may over ride the certificate check for ALL RDP connections (use it at your own risk)
Just add a new registry key as below.
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /v "AuthenticationLevelOverride" /t "REG_DWORD" /d 0 /f
Method 2
Considering if you have admin rights on the remote machine, you could actually get the crethash value from the remote machine using the below wmic command. So you could make a small batch file to get this value before you launch the mstsc and add this value in registry. I haven't included the complete batch file but thats the idea.
wmic /node:Testserver /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSGeneralSetting get SSLCertificateSHA1Hash
See this link.
Run Microsoft Management Console (mmc) and add the Certificates snap-in if you don't already have it for the computer you would like to connect to. In the Certificates, find the Remote Desktop folder, and open the certificate in that folder. On the Details tab, scroll down to find the Thumbprint value - this is the value you should copy to the registry.
I have reporting services running on SQL Server 2008 inside the domain. I'm able to hit http://localhost/reportserver without error. I can hit the same site from the web box (also in the domain name) using the internal ip of the DB box (192.169.X.X/ReportServer/ReportService.asmx.) I've looked in the SSRS logs and I see these hits being properly recorded, no errors.
However.. I have a website that uses the .NET ReportingService class to make a connection to SSRS. Using the same credentials as before, I get "Unable to connect to the remote server."
I've checked, there's no firewall active. Quadrupled checked the config in the web site to make sure it has the proper credentials and service URL for SSRS. There are also no hits in the SSRS logs when I'm trying to connect via .NET, so something is most certainly blocking access.
I've Googled my fingers bloody, and would seriously love some help. I'm sure it's some small thing, I just can't think of it.
The following change worked for me:
Remove the SSL configuration
1.1. Reporting Services Configuration Manager;
1.2. Web Service URL (click on Advanced button and then remove the SSL configuration);
1.3. Report Manager URL (click on Advanced button and then remove the SSL configuration);
Edit the file rsreportserver.config, normally it's in the path C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\ReportServer\
2.1. find out the Key SecureConnectionLevel;
2.2. change the Key's value from "2" to "0";
Could be your reporting services is exposed only to the private ip and your localhost. Try setting your domain name's static ip to the configuration. I've added a SSRS Url configuration link for your quick reference.
The following worked for me:
1. Remove the SSL if configured.
2. Go to C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config
3. In rsreportserver.config Change the SecureConnectionLevel value from "2" to "0"
The following worked for me: I Removed the SSL and set it to 0 vs 2 in the path
G:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\ReportServer file is reportserver.config file.
Basically it was previously configured with SSL at port 443 but the server has been moved to another domain, and did not know where to go to get a new SSL certificate for this domain,
So i removed the SSL config in the reporting services configuration GUI and then remove it also in the reportserver.config file.
Make sure your report URL ends with /Reportserver/ (For the purpose of .NET code calling). Also keep in mind that you should use complete URL i.e. It should include servername and domain.
Check this link
I like the other solutions however in my instance I had to update the following. For some reason or another the service wasn't able to use 127.0.0.1, localhost, or any of the other IP addresses assigned to the computer, this method however worked.
Open "Report Server Configuration Manager"
Web Service URL
Click on Advanced Button
Click the IP entry that I wanted to edit.
Click "Host Header Name" and type in the fully qualified name for the server.
Report Manager URL
Click on Advanced Button
Click the IP entry that I wanted to edit.
Click "Host Header Name" and type in the fully qualified name for the server.
After the above were done both URLs in "Web Service URL" and "Report Manager URL" were able to work once correct credentials were passed to the server.