after having installed recent WUs, I am unable to log on to the servers.
I see event id 40970 lsa downgrade attempt 0xc00002fd and also event id 14 from the KDC.
There, it tells me that the requested Kerberos Etype was 18 3 and that the available Etype is 23 18 17.
So it is clear why the logon attempt failed but I do not know how to fix it. The following was checked:
Checked GPO that the local sec pol has future enc types and AES 256 enabled
Checked User Account that AES 256 is enabled
Checked computer accounts of DC and client server that AES 256 is enabled
Checked RSOP on client machine that AES 256 is applied.
Changed pwd of affected user account
The first 4 were already correct, the changed pwd did not help.
I created a new AD account with domain admin rights and tried to logon with that one but it also failed due to the same issue.
On the DC that was not updated, i still can logon with the same account so clearly it is related to the Nov Updates. Not sure if this one could have anything to do with it: MS
Any idea what else I could do?
Seems indeed to be related to the update.
Link
What worked for me as a workaround is to allow the RC4 Etype for all DCs and Clients. Hopefully, MS will fix that asap because instead of increasing the security, they now lowered it...
Related
Good afternoon everyone,
Question about Uploading file in FMS 16 but getting an Orange Security Lock.
I already installed the Filemaker Server 16 and install SSL Certificate and domain from Go Daddy.
Then try uploading an existing file in Filemaker Pro Advanced 16, after choosing local host and type the admin console credentials im getting the orange security lock and cant upload the file. (Attached image)
I read in another thread to reinstall FMS and it should change it to a green lock, but even after a fresh reinstall, it hasn't changed it to green.
I can verify the certificate is good, Am I missing something?
I already purchase SSL certificate and Domain in Go Daddy, yet im getting in webdirect an error "Certificate is not valid".
Thanks in advance for any advice.enter image description here
It looks you have entered IP address instead of domain name. That might be the reason for orange lock. SSL verifies the domain name, not IP address.
File Upload error says Encryption password is incorrect. You have enabled encryption on rest. Enter the correct encryption password. Once file uploaded, go to admin console, open the file. Enter the encryption password and save it. Hope, it fixes the issue.
This question follows an audit on my AD where Windows servers with very old PasswordLastSet attributes have been discovered.
I'm familiar with using the Pwd-last-set attribute in order to check when an AD user has last changed his password. But what does this attribute mean when talking about a computer-type object like a laptop or a windows server ?
The Microsoft documentation states it is "The date and time that the password for this account was last changed". I don't think this means the local administrator of the computer, since I've clearly not changed mine at the date my Pwd-last-set attribute indicates.
Finally, if it isn't the local administrator nor my account, how can I set a new password that will refresh the attribute ?
EDIT
So the password is actually the Machine Account password used for communication between the computer/server and the DC
It's supposed to be renewed every 30 days on default Windows settings through the following registery key : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
I still don't have a way to easily force the renew of this password but found some leads :
Put the MaximumPasswordAge in the registery to a low number and restart the machine
Use the "Reset Account" options when right-clicking the object in the active directory -> What are the consequences for a server ?
Use the Reset-ComputerMachinePassword Powershell command -> What are the consequences for a server ?
I'm integrating Bitvise client into my winform app. I am using Bitvise SSH Client command line (stnlc.exe in the app's directory) to do so. My app needs to have multiple connections at the same time.
It works well with some addresses, but some other it doesn't. This is the command that I'm using:
"C:\Program Files (x86)\Bitvise SSH Client\stnlc.exe" -profile="C:\Users\AutoOffer\AutoOffer\bin\Debug\data\sshprofile.bscp" -host=<myhost> -port=22 -user=<username> -pw=<password> -ka=y -proxyFwding=y -proxyListIntf=127.0.0.1 -proxyListPort=<port>
And this is the error I got:
Bitvise SSH Client 6.45 - stnlc - free for individual use only, see EULA
Copyright (C) 2000-2015 by Bitvise Limited.
Connecting to SSH2 server XX.XX.XX.XX:22.
Connection established.
Server version: SSH-2.0-dropbear_0.46
First key exchange started.
ERROR: The SSH2 session has terminated with error.
Reason: Error class: LocalSshDisconn, code: KeyExchangeFailed, message: FlowSshTransport: no mutually supported key exchange algorithm.
Local list: "ecdh-sha2-1.3.132.0.10,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha1".
Remote list: "diffie-hellman-group1-sha1".
I tried to connect manually by the Bitvise app with GUI and it successfully connected!
I also updated my bitvise version to the latest (6.45).
Local list: "ecdh-sha2-1.3.132.0.10,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha1".
Remote list: "diffie-hellman-group1-sha1".
So it looks like the remote side just supports diffie-hellman-group1-sha1, which is not supported on your side.
On Bitvise SSH Server Version History I read:
The 1024-bit fixed prime Diffie Hellman key exchange methods, diffie-hellman-group1-sha1 and gssapi-group1-sha1 with Kerberos 5, are now disabled by default, due to doubts about continuing security of Diffie Hellman with a 1024-bit fixed prime. Compatibility with most older clients should be retained via the diffie-hellman-group14-sha1 method, which uses a 2048-bit fixed prime. We recommend migrating older SSH clients to new versions supporting ECDH and ECDSA.
So it looks like you have to modify the settings and allow 1024-bit fixed prime Diffie Hellman key exchange methods. Otherwise you will not be able to connect. As explained it is of course better to change the ssh server settings.
Also, please note that running stnlc as a service is a possibility. With it, the tunnel can be started even without the user having to log on, and can be restarted upon dropping.
Be aware that wrapping and running stnlc as a service (using eg. nssm or winsw) absolutely requires adding the unat=y option to prevent the service from going interactive and failing.
I am learning about kerberos and i have few questions about it that i didnt found on the network and i wanna ask you.
The questions are:
What happen when I change user's password? What really gonna behind? What the service it use? I want to know what the steps and how the KDS behave after change password
Why kerberos's name called about the hades dog / 3 head dog? What the connection between them?
In kerberos system how I can see my tickets I recive from the KDC?
Thank you in advance.
I only have an answer to your 2nd question.
The reference to the three-headed dog is that there are 3 different entities:
The client system
the Authentication Server
the Service Server (the thing you're trying to access)
Most authentication protocols only involve the client and server.
From "Kerberos: The definitive guide" book by Jason Garman:
The Greeks believed that when a person dies, his soul is sent to Hades to spend eternity. While all souls were sent to Hades, those people who had led a good life would be spared the eternal punishment that those who had not would have to endure. Cerberus, as the gatekeeper to Hades, ensured that only the souls of the dead entered Hades, and he ensured that souls could not escape once inside.
As the gatekeeper to Hades, Cerberus authenticated those who attempted to enter (to determine whether they were dead or alive) and used that authentication to determine whether to allow access or not. Just like the ancient Cerberus, the modern Kerberos authenticates those users who attempt to access network resources.
You can see list of your tickets with klist command. If you mean literally see file where tickets stored, this command provides you with path to ticket cache as well. On *nix systems using MIT Kerberos it's /tmp/krb5cc_%{uid} by default. This command also should work in windows, but I'm not sure is it installed by default.
****1. What happen when I change user's password?****
They will get a new password, nothing special really, it shouldn't affect an existing kerberos ticket cache that i am aware of as long as the ticket is valid. If they have to enter their password anywhere at a later point for example if you have to run the kinit command to get a ticket where you enter your password then you must use the new password.
There shouldn't be much "sync" time or anything but it is vital that the time on your server is synced with the KDC as Kerberos is strict about times being in sync, by default there is a 5 minute clock skew, so it can only be off my no more than 5 minutes or things will start failing. Typically you would do this on linux by running the ntpdate command to sync the clocks.
***1a. What really gonna behind? What the service it use? I want to know what the steps and how the KDS behave after change password****
What happens depends on your setup, of which you have a variety of options but here a few more common setups.
The most common setup is running a corporate Active Directory environment. In a basic Active Directory setup your Domain Controller(s) run your KDC automatically. So for this you would just reset your Active Directory users password then pretty much be good to go, it will take care of the changes to the KDC for you.
The second would be running an OpenLDAP type environment for your users in place of Active Directory where you would change the passwords in OpenLDAP then update the password in the MIT Kerberos KDC using the kpasswd command to reset the password for your principal on the MIT KDC unless you have setup something such as pass-through authentication.
The third setup I see in an MIT Kerberos KDC with no LDAP environment whatsoever. Usually the kerberos users are local user accounts on the operating system. In this case you would just update the password on the MIT KDC using the kpasswd command I mentioned before to update the keberos principal password for the user on the MIT KDC.
2. Why kerberos's name called about the hades dog / 3 head dog? What the connection between them?
In addition to build on the previous answers Kerberos is similar to the 3 headed dog since it performs a 3 way handshake when authenticating. The three pieces are the Key Distribution Center (KDC), the client, and the server. This article gives a good explanation in detail, it is slightly off as it is talking about specific software but at the bottom of page 1 from Paper 476-2013 Kerberos and SAS® 9.4: A Three-Headed Solution for Authentication by Stuart Rogers, SAS Institute you will find the specific details.
3. In kerberos system how I can see my tickets I recive from the KDC?
If you have a ticket you can run the klist command. Append a -ef for klist -ef to see your encryption types along with any flags such as forwarded, initial, renewal, and others. See the MIT Documentation in klist documentation at http://web.mit.edu/Kerberos/krb5-1.13/doc/user/user_commands/klist.html .
You can get a ticket by running the kinit command then entering your principals password.
You can destroy a ticket cache by running kdestroy to clear your current tickets. This won't necessarly remove them from your cache directory though.
If you have a keytab file you can see details about it by running klist -kt /path/to/myuser.keytab to see the principal the keytab is for. There will be a principal per encryption type you are using, that is why it lists multiple of the same sometimes. You will see a KVNO number, which is your key version number, this number should always match for each principal.
Answers to you questions are:
Once the password for the principal is changed then after that point of time whenever you are running kinit command to get the ticket you should use new password
The name Kerberos was taken from Greek mythology; Kerberos (Cerberus) was a three-headed dog who guarded the gates of Hades. The three heads of the Kerberos protocol represent a client, a server and a Key Distribution Center (KDC).
To view the ticket you get from KDC you can run klist command if will give the details of principal , ticket lifetimes etc.
The location where ticket really exists depends on what you have given in /etc/krb5.conf which by default is default_ccache_name = FILE:/tmp/krb5cc_%{uid}
I have a MATLAB server which hosts a license manager (LMTOOLS by Flexera Software LLC) and few clients.
When you run use a toolbox function such as datestr(busdate(date)) you automatically checkout the Financial Instruments toolbox from the server. The license is returned to the server only when you close the session. Is there a way to force a particular client to return the license? A user forgetting to close his/her session can affect everyone as the administrator has no way to return the license to the server.
You can use:
lmutil lmstat -a -c "MYPATH\network.lic" --> to check license-borrower details
Output: ......john.doe PCNAME PCNAME (vxx) (SERVER/3300 123), start Tue 8/5 10:30
I tried using:
lmutil lmremove -c "MYPATH\network.lic" Fin_Instruments_Toolbox john.doe PCNAME PCNAME
but it returned just 1 line output lmutil - Copyright (c) 1989-2012 Flexera Software... and did not check-in the borrowed license. Any idea how to do this without closing the borrowing Matlab session? I even disconnected the client from the network but that didn't help.
Useful links: weblink1 weblink2
There's no way to do that - the client has to close their MATLAB session.
Mathworks use Flexnet and doesn't allow 'reread' or 'lmremove' like the other editors that use Flexnet. If I must make available a token I try the following solutions :
stop/start of the license server;
block the IP address of the computer where the toolbox is used.
Start/stop :
The users that have a token can use it during 20 minutes before lost it if the license server doesn't respond, but some new users can't take a token. Before make this, I check the number of Tcp/IP ports opened for the license service. I know that below 180/190 sessions (users), I can make a start/stop of the server.
If the faulty client doesn't make an other checkout after the start of the license server, the token will be available for other users.
If the user use a floating (CN) license and try to make an 'OUT' too rapidly (like a while(1)), I modify the option file to block the user by putting an 'EXCLUDE' for the user - a log file that grows continuously could be dangerous for the server. Or, if the user takes too many CN tokens for the same toolbox, I put a 'MAX' directive for him.
Block the IP address :
If the client using a token doesn't contact the server during 4 hours, the server consider that the token is 'Idle' and get it, it makes an 'IN', then the token is available. I use a 'Iptable' command to block the IP of the user's computer. This is only valid if the computer isn't shared between many users like a cluster node. The 4 hours is the value of the 'TIMEOUT' directive, but don't hope to reduce this value, even if you change it in the option file, you can only increase it. The minimum value is locked by Mathworks.