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 ?
Related
All the docs and help threads I can find reference connection strings with Authentication=ActiveDirectoryIntegrated to hit SQL with AAD integration. If I'm using SSMS I can also choose "Active Directory Universal" which gives a prompt if MultiFactorAuth (MFA) is required.
I want to use powershell to invoke-sqlcmd, or even sqlcmd.exe directly -- do either support an MFA flow? How else can I get commandline queries against an AAD-enabled MFA-enabled SQLAzure instance?
invoke-sqlcmd : Failed to authenticate the user NT Authority\Anonymous Logon in Active Directory
(Authentication=ActiveDirectoryIntegrated).
Error code 0xCAA2000C; state 10
AADSTS50079: The user is required to use multi-factor authentication.
Trace ID: 54f0cb31-2f0f-4137-b142-b312a6cd441b
Correlation ID: 70204904-576c-4db5-9c3b-6ccd7fe6b409
Timestamp: 2017-02-09 22:56:39Z
I've seen https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication, and everything was working fine right up until MFA either was applied, or when it realized it was time to re-auth and prompt.
If there is a way for me to cache creds so ActiveDirectoryIntegrated generally works, and I just need to re-auth and re-cache when it decides it is time to force an MFA prompt I'm also open to that.
I want to use powershell to invoke-sqlcmd, or even sqlcmd.exe directly -- do either support an MFA flow?
No. As far as I know, the SSMS is the only tool currently enabled for MFA through Active Directory Universal Authentication.( refer here)
If you have any idea or suggestion about Azure SQL database, you can submit them from here.
Beginning with version 15.0.1, sqlcmd utility and bcp utility support Active Directory Interactive authentication with MFA.
I installed Kerberos for Windows on a new set-up Windows 8.1 machine.
Domain: not set
Workgroup: WORKGROUP
I edited the krb5.ini file in C:\ProgramData\MIT\Kerberos5 directory like this:
[libdefaults]
default_realm = HSHADOOPCLUSTER.DE
[realms]
HSHADOOPCLUSTER.DE = {
admin_server = had-job.server.de
kdc = had-job.server.de
}
After a restart, I made a kinit -kt daniel.keytab daniel to authenticate me against the Realm via console. Also getting a ticket by user and password via the Kerberos Ticket Manager seems to work fine, as the ticket is shown in the UI.
What I'm wondering about is, that when I call a klist I get an empty list back, which says something like cached tickets: 0:
This seems not normal to me, as my Ubuntu computer shows valid tickets by klist after a kinit.
What am I doing wrong? Is there some more configuration to do? Sometimes I read about a ksetup tool, but I don't know which settings here are neccessary and which not...
============================================================
After I set
[libdefaults]
...
default_ccache_name = FILE:C:/ProgramData/Kerberos/krb5cc_%{uid}
in my krb5.conf, the kinit command via console and via Kerberos Ticket Manager creates a file in the specified path. So far everything looks good.
But: The kinit command creates tickets with very different file names (long vs. short), depending if I run the console as "admin" (short name) or not (long name), see the screenshot below. The Kerberos Ticket Manager only shows one of the tickets:
If run as admin:
Shows the ticket I created via admin console
Creates ticket files with short file names
If run as normal:
Shows the ticket I created via "normal" console
Creates ticket files with long file names
The klist command still doesn't show the cached tickets, independent if console was opened as admin or not.
The MIT Kerberos documentation states that...
There are several kinds of credentials cache supported in the MIT
Kerberos library. Not all are supported on every platform ...
FILE caches are the simplest and most portable. A simple flat file format is used to store one credential after another. This is the
default...
API is only implemented on Windows. It communicates with a server process that holds the credentials in memory... The default
credential cache name is determined by ...
The KRB5CCNAMEenvironment variable...
The default_ccache_name profile variable in [libdefaults]
The hardcoded default, DEFCCNAME
But AFAIK, on Windows the hard-coded default cache is API: and that's what you can manage with the UI. kinit also uses that protocol by default.
I personally never could use klist to use that protocol, even with the "standard" syntax i.e. either
klist -c API:
or
set KRB5CCNAME=API:
klist
On the other hand, if you point KRB5CCNAME to a FILE:***** then you can kinit then klist the ticket; but it will not show in the UI and will not be available to web browsers and the like.
If klist command doesn't show the keys even after setting environment variable like KRB5CCNAME (i.e. set KRB5CCNAME=C:\kerberos_cache\cache\krb5cache, its a file not a directory. You'll have to create parent directory manually), then chances are that the klist command that you're running is not from MIT Kerberos Windows installation in C:\Program Files\MIT\Kerberos\bin but rather the klist command from Windows itself in C:\Windows\system32.
You can check that out by running which klist if you have cygwin tools. In this case, simplest solution is to copy klist.exe into MIT Kerberos installation's bin directory as a new file i.e. klist_mit.exe. Cache entries should be shown if you run klist_mit command.
I'm currently running into an issue where we changed over the name of a server (windows 2012). With the old name everything worked fine, after the name change it appears that the app pool identity is stuck with the old machine name in the machine account.
The site is using win auth to connect to our SQL server and provides an error:
LOGIN FAILED domainname\oldmachinename$
I notice when I change the app pool identity, the error changes, so it seems to be stuck with the old computer name, even though it's updated in local server data and control panel system properties.
How can I force the new name to be seen as the machine account?
I would remove the machine from the domain, change the hostname, re-join it to the domain, and that should alleviate the incorrect hostname issue.
In Windows XP, I'm going to add a new user with a simple password. It prompts that the password does not meet the password policy requirements. I've not set a policy!
Then I found that i should use gpedit.msc to change this policy. But it's disabled and I'm unable to change the default policy. I don't know how to change this policy.
Can you use Start -> Run -> secpol.msc, and then navigate to Account Policies and then Password Policy and change it there?
If not, then maybe you can do this by editing the registry directly using this:
Set strong password policy in Windows XP
Oh, I found it! The computer was joined to a domain. So I couldn't create a user with a simple password, even in the local Windows. I left the domain and the fields got changeable!
Microsoft is always weird.
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}