I have written a service that monitors if my app is running and starts it if not. In result the app is run as a "system" user - which is the way I want it to be. I have several of those installations working properly.
The app should mount a network share that is in this case available on a linux samba server. The problem is that when running the command:
net use X: \\IP\share_name /user:login password
an error is displayed:
System error 1312 has occured.
A specified logon session does not exist. It may already have been
terminated.
I have run some checks and it turns out that the X: drive in local system is available, the server is online, the share is available, the credentials are OK, there are no other net use sessions running in this system. Also I have found out a strange behavior: running identical command as a standard user gives proper results and the drive is mounted properly.
Do you have any suggestions what might be the problem and how to solve it?
Additionally I am not a domain member, and the system that shows the error is Windows 7 Pro. I have other machines in the same network that do work properly without the error.
I have had the same issue some time ago. It helped when I introduced a domain name (even if you are not a domain member) before the login.
I your case try this command:
net use X: \\IP\share_name /user:whatEver\login password
Test this command:
EXEC XP_CMDSHELL 'net use Z: 192.168.3.55backupShare password#123 /User:domainuser'
I've just run into the same problem on upgrading to Windows 10 PE 2004 (19041). The older Windows 10 PE 1803 (17134) did not require the dot before the username.
Here's the solution:
Put the password before the user (this is the argument order given by net use /?).
Add the server's name, IP or a dot and then a backslash (.\) before the username .
Use:
net use X: \\IP\share_name password /user:.\login
or
net use X: \\IP\share_name password /user:IP\login
If you have arguments with spaces, add parenthesis around them:
net use X: "\\IP\share name" "pass word" /user:".\test user"
Related
First of all, a rookie, related to VPN/Security issues, so really
forgive me for whatever error I make while describing my problem,
and hope I'm able to make it clear.
Our contractors changed AVIATRIX-OKTA VPN for AWS-VPN with OKTA
Authentication, they send as an .ovpn file, that works ok for
Windows/MAC using AWS-Vpn-Client application software, but a
couple of us using Linux boxes (Ubuntu specifically) run the
described method in AWS which is: openvn config-file.ovpn,
and it does not work.
It simply asks for usr/pwd an then it fails with auth error (we use our OKTA credentials)
, seems nothing is configured to go to OKTA, open a browser or whatever it needs to do.
As an aside note, we can connect without any trouble to our k8s cluster using OKTA
client libraries, no sure is this is useful or not, just in case.
The .ovpn file looks like this
client
dev tun
proto tcp
remote random.cvpn-endpoint-xxxxxx.yyy.clientvpn.us-west-2.amazonaws.com 443
remote-random-hostname
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-GCM
verb 5
<ca>
....
....
....
</ca>
auth-user-pass
auth-federate
auth-retry interact
auth-nocache
reneg-sec 0
An interesting thing to notice is that openvpn complains about auth-federate
seems not to recognize it, so I started using gnome network-manager which seems
to accept this configuration, but getting Auth error too.
After this I tried openvpn3 which didn't complain about configuration,
but still getting the same error.
I also tried adding TOPT token to password and the same problem
Any help on how to configure it, or just know if it is possible, will be greatly welcome
, seems there is very little information around this in the net
and we are really stuck on this, we are willing not to change OS or machines as they
are asking to, or using VM just to connect.
Thanks in advance,
We have tried the solution mentioned in the following URL and it worked for us:
https://github.com/samm-git/aws-vpn-client/blob/master/aws-connect.sh
The detailed working of this solution is explained in :https://github.com/samm-git/aws-vpn-client/blob/master/aws-connect.sh.
We have made few changes in the configuration files to make it work.
Removed the following lines in vpn.conf.
auth-user-pass
auth-federate
Made the following change in line 38 in the script aws-connect.sh.
open "$URL"
to
xdg-open "$URL"
Finally I got an answer from AWS people:
If the Client VPN endpoint is configured using SAML-based
authentication (such as Okta), then you have to use the AWS-provided
client to connect:
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/client-authentication.html#saml-requirements
And the promise to update del client documentation with a WARNING about
this.
I am trying to connect PSYCOPG2, however it is my first time doing so and I haven't created any user. All tutorials I see supose I have already created one and I simply can't connect. I have seen that there is a default user for Postgres and I have tried the following codes and received the following errors:
conn = psycopg2.connect(database="postgres", user="postgres", password="postgres", port=5432)
Error FATAL: password authentication failed for user "postgres"
con = psycopg2.connect(database='postgres', user='postgres')
Error fe_sendauth: no password supplied
What else should I try, please?
Some installers ask for a password during installation (really is used for initialization of the database after installation of the software), then you need to specify this password to connect as the 'postgres' user, even from the local machine. This is common for Windows installers. If you don't remember what you told it, it might be easiest just to reinstall.
Linux installers are not likely to do this, they usually use 'peer' method with no password. But this only applies when you use a unix-domain socket to connect. Your python code suggests that that is what you are doing (since that is usually the default on linux when no host is provided), but the log-file message suggest you specified the host of ::1 to connect to.
I am running the CUPS in Linux Debian machine. Using the CUPS I am sending the print request to Windows XP machine. I have enabled the 445 and 139 port and I am able to connect the Windows Machine. Printer is connected to the Windows Machine.
I am sending the print request using the following command
lp -E -d < Printer Name > file name.
After sending I am checking the printer status using the following command
lpstat -p < Printer Name >
I am getting the below error message when I execute the above message.
unable to connect to cifs host will retry in 60 seconds..
When I checked in the log I am getting the below error message.
session setup failed: NT_STATUS_LOGON_FAILURE and NT_STATUS_BAD_NETWORK_NAME
The DeviceURI is like below in /etc/cups/printers.conf
smb://username:password#IP Address of windows Machine/printer_Name
Please let me know if the password is having '#' symbol, how can we specify the '#' with actual syntax in DeviceURI ( user:password#IP )
Unfortunately you provide not enough detailed info about your specific setup. So I will make an effort to take several potential problems into account and give hints how to overcome them:
I.
Did you use the correct share name for your shared Windows printer?
To find out, use this command:
$ smbtree -U windowsusername
You might see something like the following output:
WORKGROUP
\\MURUGA-PC
\\MURUGA-PC\G
\\MURUGA-PC\Z
\\MURUGA-PC\Public
\\MURUGA-PC\print$ Printer Drivers
\\MURUGA-PC\EPSON Stylus CX8400 Series EPSON Stylus CX8400 Series
In other words: your printer's share name may contain spaces. But you cannot use spaces in the device URI for CUPS! What now?
Easy: (1) Either rename the share name on the Windows side. (2) Or escape the space by using %20 instead:
smb://muruga:mysecretpassword#muruga-pc/EPSON%20Stylus%20CX8400%20Serie
II.
Is your Windows XP by any chance using Kerberos authentication? For example, because it is part of an Active Directory environment? Then you should refer to this document on cups.org:
Configuring CUPS to Use Kerberos
Kerberos authentication does not work with username/password, it uses 'tickets'.
III.
Otherwise, if your Windows XP machine is part of a "standard" domain, you may be more successful by ditching your device URI of smb://username:password#ip-address-of-windows/printer_name and use this instead:
smb://username:password#domain_name/windows_host/printer_Name
The username you use has to be the Windows user name (with his/her password) who installed the printer on Windows!
IV.
Alternatively, you may have success by using IPP to print to Windows (though XP needs an IPP-enabling extension installed, provided by Microsoft). Be aware that MS is using a non-standard syntax for their device URIs (using port 80 or 443), and their version of IPP is still 1.0 (which always remained in "draft" status and never made it into an official release by the IETF):
DeviceURI https://mywindowsprintserver/printers/printername/.printer
or
DeviceURI http://mywindowsprintserver/printers/printername/.printer
For username/password authentication to this printer, you need
AuthInfoRequired username,password in /etc/cups/printers.conf and
DefaultAuthType Basic in cupsd.conf.
To use Kerberos, you need
AuthInfoRequired Negotiate in /etc/cups/printers.conf and
DefaultAuthType Negotiate in cupsd.conf.
If the whole setup is in a household with a private LAN/WLAN, you may want to consider removing all access controls (first on the Windows print server side, then):
AuthInfoRequired None in /etc/cups/printers.conf and
DefaultAuthType None in cupsd.conf.
If your problem is that your password contains a '#'-character, then try this:
smb://username:'p#ssword'#domain_name/windows_host/printer_Name
or
smb://username:p%40ssword#domain_name/windows_host/printer_Name
I'm trying to set up a remote desktop session for monitoring specific systems at my place of work. I only have access to a Linux machine and I need to connect via a terminal server gateway. I am using FreeRDP to do this and i am using the following command to create the connection:
xfreerdp /d:** /u:***** /p:******* /g:******.************.***
/v:****.*********.***** /port:3389 /size:1920x1080
I have hidden all connection details per my supervisors request however both he and I verified the correct information is entered into the fields.
When I send the connection through I get the following error:
Connected to ******.************.***:443
Connected to ******.************.***:443
TS Gateway Connection Success
Got stub length 4 with flags 3 and called 7
Got stub length 4 with flags 3 and called 6
SSL_read: I/O error: connection reset by peer (104)
Rpc_client_frag_read: error reading header
Would anyone have any idea of what I might be missing? I have even tried adding
/sec:rdp
to the script and even that produced the same error
Try rdp from a Windows system (or have someone else try from their system, since you don't have direct access to Windows). I know it won't solve your problem, but it may give you better information. I'm in a similar situation and got the same error message. I tried remmina instead of xfreerdp and got even less information than xfreerdp spits out.
From a Windows VM, at least I could tell when I got my domain\username & password right -- it told me my account was not allowed rdp access to that server. I'm figuring that means that there are accounts that can rdp in, but mine is not among them. Along the way, though, I found that the remote was using a certificate from an untrusted authority, which was useful information for my case.
If your Linux is old or hasn't been updated, do so. Your certificate store may be out of date. But it may also be that your company's Windows domain has certificates that Linux doesn't know about. It could be a simple matter that you're lacking the company-supplied cert (because they push it to all Windows machines on the domain, but your Linux machine doesn't get that "benefit").
We are writing softwares that run on both Windows and Linux, and plan to use Windows Active Directory for authentication. I am struggling with the issues described below, and would appreciate any help very much:
Domain name: CORP.COMPANY.COM
Test programming running on the one Linux machine: host1.corp.company.com
The test program comes from the gss-sample from krb5-1.11.3 downloaded files.
The server will be named "gssapitest".
Based on "Step-by-Step Guide to Kerberos 5(krb5 1.0) Interoperability(from Microsoft)
,
First create a user "host1" in the AD to represent the host
host1.corp.company.com (the linux machine).
Use ktpass to generate the keytab (run from Windows):
ktpass /princ host/host1.corp.company.com#CORP.COMPANY.COM /mapuser host1 /pass
hostpassword /out file1.keytab
Now in AD, create another domain user "gssapitest" to represent the test server program, and map user similarly:
ktpass /princ gssapitest/host1.corp.company.com#CORP.COMPANY.COM /mapuser
gssapitest /pass gssapitestpassword /out file2.keytab
copy file1.keytab and file2.keytab to the Linux machine host1, and merge them to /etc/krb5.keytab.
In Linux, "ktutil" shows the content of /etc/krb5.keytab like the following:
slot KVNO Principal
1 4 host/host1.corp.company.com#CORP.COMPANY.COM
2 5 gssapitest/host1.corp.company.com#CORP.COMPANY.COM
On windows, register the service (using "setspn") for the Linux server program so that the result looks like (2 entries, one with mapped host name, the other with actual host name, for testing purpose. If only one entry, no matter which one, the result was the same):
Registered ServicePrincipalNames for
CN=xxxx,CN=Users,DC=corp,DC=company,DC=com:
gssapitest/host1:2001
gssapitest/host1.corp.company.com:2001
Now I start the server this way:
gss-server -port 2001 gssapitest
and start the client from another terminal this way:
gss-client -port 2001 -user xxxx -pass xxxxpassword host1.corp.company.com
gssapitest "abcd"
The error shows on the server side:
GSS-API error accepting context: Unspecified GSS failure. Minor code may
provide more information
GSS-API error accepting context: Wrong principal in request
What could be the likely cause of this? I'd like to know if the step I outlined about
are all necessary. and which one are not needed at all or are incorrect.
(Note: I have tried to log in to the Linux with both a local user account and
a domain account in CORP.COMPANY.COM, the result shows the same error.
also the nslookup shows correct IP to host mapping for the linux machine).
I would not include the port number when using setspn; I'd expect gssapitest not gssapitest:2001.
In addition, use gssapitest#host as the service name in the call to gss-client;
gss-client -user xxx -pass xxx -port 2001 hostname gssapitest#hostname "test message"
You can use krb5 tracing to get much better logging about what's going on:
export KRB5_TRACE=/tmp/trace.client # and run client
Similar for the server.
I did some test runs, and in my case, the problem seems to be this: I made changes to my mapped user, i.e., gssapitest (In "Active Directory Users and Computers", I unchecked "Use DES encryption types for this account" under "Account" tab for this user) after running "ktpass" and merged the output file to the krb5.keytab in the Linux machine.
To fix this problem, I checked the "Use DES encryptiuon types for this account" again from inside the Active Directory, then go to the Linux machine, run "kdestroy" before starting my server and client programs. Then it worked.
If anyone is having similar problems, you may want to look into this possible cause. Thanks.