I'm trying to create a program which echo's a current user.
As the program needs to be run as admin using the task scheduler the %username% always returns admin, NOT the user.
What I'm looking for in the end is a batch that echo's time stamp, user info and pc info every time a user logs on, off, locks, unlocks, switches user, ...
I ran into similar issue before, try using whoami
The current user IS admin. Windows supports multiple users (although only 1 live one at a time). What you can do is query for users logged on and choose the interactive one.
Lists of potential users
wmic PATH Win32_SystemUsers get /format:List
wmic PATH WIN32_UserAccount get /format:List
wmic PATH WIN32_Account get /format:List
All the users logged on incl system accounts.
NB Administrators will have two logons - one as a limited user and one elevated.
wmic PATH Win32_LoggedOnUser get /format:List
To find info about the logon types
wmic PATH Win32_LogonSession get /format:list
List of logon types - you want 2.
LogonTypeData type: uint32Access type: Read-only
Numeric value that indicates the type of logon session.
Value
Meaning
0
Used only by the System account.
Interactive2
Intended for users who are interactively using the machine, such as a user being logged on by a terminal server, remote shell, or similar process.
Network3
Intended for high-performance servers to authenticate clear text passwords. LogonUser does not cache credentials for this logon type.
Batch4
Intended for batch servers, where processes can be executed on behalf of a user without their direct intervention; or for higher performance servers that process many clear-text authentication attempts at a time, such as mail or web servers. LogonUser does not cache credentials for this logon type.
Service5
Indicates a service-type logon. The account provided must have the service privilege enabled.
Proxy6
Indicates a proxy-type logon.
Unlock7
This logon type is intended for GINA DLLs logging on users who are interactively using the machine. This logon type allows a unique audit record to be generated that shows when the workstation was unlocked.
NetworkCleartext8
Preserves the name and password in the authentication packages, allowing the server to make connections to other network servers while impersonating the client. This allows a server to accept clear text credentials from a client, call LogonUser, verify that the user can access the system across the network, and still communicate with other servers.
NewCredentials9
Allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identify, but uses different credentials for other network connections.
RemoteInteractive10
Terminal Services session that is both remote and interactive.
CachedInteractive11
Attempt cached credentials without accessing the network.
CachedRemoteInteractive12
Related
I want to impersonation a user on a windows server (2012/2016/2019) in a domain environment.
This should happened by a administrator account with SE_DEBUG and SE_IMPERSONATE privileges.
GetAccessToken()
DuplicateTokenEx()
CreateProcessWithTokenW(token, LOGON_NETCREDENTIALS_ONLY, L"c:\\windows\\system32\\cmd.exe", NULL, 0, FALSE, NULL, &si, &pi)
Until now its working fine.
But i have to read a fileshare on another server in context of the impersonated user/token.
On localhost the created process have all permissions from the original user/process.
If try to access a fileshare or any other server on the Network this results in "Access Denied".
I found out that it is depending on the logon type if users credentials are available on the system which is needed to connect to another system. (double hop)
But also if the impersonated process is started from an interactive logon (tried RDP und runas.exe)there seems to be no rights on remote systems.
I checked the Logon Type of the token GetTokenInformation() to get session id and then call LsaGetLogonSessionData() to get field LogonType.
Where is the difference between this and get TokenOrigin Variable from GetTokenInformation?
Which configuration allows me to access remote share with the impersonated token?
There's no difference in impersonating a admin vs non-admin, but a LOCAL admin does not necessarily have access to the another machine. A domain user does.
I create a service which is defined to Log On as Administrator.
This service performs system("net use Z: \... /user:user password") and completes successfully.
If I (as Administrator) run "net use" I see Z: indeed added, but with status - unavailable.
I tried adding ImpersonateLoggedOnUser to the service, but that didn't help.
OS: Win XP
What am I missing?
ImpersonateLoggedOnUser doesn't impersonate the logon session from the user token, just the security context. CreateProcessAsUser, however, should be able to create a new process in the logon session associated with the specified user token.
Note that calling LogonUser to get a user token for CreateProcessAsUser won't work, because this token won't be in the same logon session as the logged-on user. You have to find one of the user's processes and duplicate its token.
Logon sessions are not well documented, but all you really need to know that each time a user is authenticated a distinct logon session is created, and that each such logon session has a distinct set of network drive mappings. Logon sessions are not the same as terminal services sessions.
In Windows Vista and above, two logon sessions are created when an administrative user logs in, one associated with the restricted token and one associated with the elevated token.
You can look up the logon session associated with a token using the GetTokenInformation function with the TokenStatistics option. The logon session is identified by the AuthenticationId LUID.
To make this work, your service would need to first figure out when a user has logged in, wait for a process associated with the new session to start, make sure it's not an elevated process, then duplicate the access token.
Instead, your best option is going to be to split the application into two components. One component will run as the user (you would probably launch this automatically using the Run key) and be responsible for mapping the network drive. It can contact the service to obtain any information it needs, either via a named pipe or a registry key.
Windows logs on Administrator and uses the logon token to start the service. If you logon interactively Windows creates a logon token for you. The two tokens are not related to each other. Mapped devices are mapped for one session/logon token, therefore if the service maps a device you do not see it in your logon session.
I've recently taken over a script from someone who's left the company and it recently started failing. The code looks up a specific user and sends them an e-mail.
I've nailed the culprit line that fails to be (user and passwords is set to my personal account):
my $dbh = DBI->connect('dbi:ODBC:IDM', $idm_user, $idm_passwd)
from this database the script selects the E-mail from a specified user login name.
I can't seem to find any documentation on the database IDM and was wondering if anyone knows of it?
Is it a built in Microsoft Exchange DB or Windows domain DB?
Thanks!
That line is connecting to an ODBC data source called IDM defined in the ODBC data source administrator in that system.
Ewww...
I have a feeling that the guy wrote his own database to do this particular task, and maintained that database.
I had to do something like this and used Net::LDAP to read the user's email address from the Windows Active Directory, then used Net::SMTP to write the email. Of course, your Windows Active Directory must be configured to allow for LDAP access, and your Outlook email must be configured to allow for SMTP based mail.
You can try something like Win32::AD::User to fetch the user's email address directly from Active Directory, but I have a feeling that you won't have read/write access to it.
If you can figure out how to fetch the user's information, you can try Mail::Outlook to write the actual email.
I never used either of these modules. I guess I've been lucky that my Window sites allow LDAP access and SMTP.
We have a system using two machines to do some processing. Let's call the machine that does the processing PROCESSOR, and the machine giving it items to process SERVER. Both are running Windows Server 2008. We have one Windows Service running on SERVER which needs to use MSMQ to send messages to a public queue PROCESSOR.
On PROCESSOR, we have another Windows Service which pulls items from the queue for processing.
The two machines are in the same domain, and all works fine if we run both services under accounts with domain admin privileges. However, we need the accounts to have the minimum privileges possible (particularly for the service on SERVER).
Before elevating the rights of the account we're using for the service on PROCESSOR, I tried giving it full rights to MSMQ. However, this didn't seem to be enough, and as soon as the service tried to do anything with MSMQ (first thing it does on starting is to check if relevant queues exist), I got an exception saying "Access to Message Queuing is denied".
Does anybody know what permissions need to be granted to an AD account in order for it to be able to use MSMQ?
Thanks,
Andrew
Run your service under a defined system account, like (I believe Network), then set the permissions on the MSMQ to full control for that.
When I've used this in the past I just cheated and allowed access to "Everyone". But in a domain setting the best way is to create a domain user and set that for the service and permissions on the MQ.
You need to set permissions on the objects in Active Directory.
So you'll need Get Properties permission if you are querying objects, for example.
This should be on the MSMQ object under the computer object and the queue object(s) under the MSMQ object.
Also, the defaults are going to be restricted to allowing everyone to send but not receive so you will need to add that access for the domain account you are using to be able to read messages.
Typical ISP setup. One server is the web server, another is the DB SQL server. There is a local administrator account, let's say XYZ, created on both machines. So when I log in remotely, I am either WebServer\XYZ or DBServer\XYZ, depending where I log in.
Now, when I login to SQL Server SSMS on DBServer using Windows Authentication, and execute "SELECT SUSER_NAME()", I get DBServer\XYZ. That makes sense since it's picking up the fact that I logged in with those credentials.
Now, move over to the WebServer. I remotely login as WebServer\XYZ. I've installed the SQL client components there. When I launch SSMS, choose the DBServer, login with Windows Authentication, and execute "SELECT SUSER_NAME()", I somehow get DBSERVER\XYZ, instead of what I would assume should be WebServer\XYZ.
Somehow, the XYZ from the WebServer becomes the XYZ from the DBServer. Why is that? How does that happen? Surely, it can't just be because the names happen to be the same?
I've heard of trusted domains, but neither machine is a Domain Controller, so I don't have access to that info. How can I tell if it's trusted or not, without the GUI tools?
The reason I ask the question is because, I'm trying to implement the same thing on my XP laptop (using Virtual PC), so I can imitate the production environment, but I'm not having any luck.
The NTLM challenge between machines is a little more complex #Quassnoi indicates but it is similar. The machines may well be in the same domain or trusted domains, but the accounts you are using are local machine accounts, scoped only to the local machine's security access management.
Local SAM accounts patterned as machinename\userid are non-propagatable. You'd experience a series of negotiated fallbacks when you tried to authenticate against external resources using that account as follows:
Pass current domain/username/password hash token - it'll fail, the account is untrusted
Fallback - revert passing hash of UserID + Password
Fallback - revert to connecting as anonymous credentials.
The fallbacks can also be disabled through configuration, it is very common for anonymous authentication to be prevented.
As #Quassnoi indicates in this instance you managed to login using the #2 fallback.
To enable account credentials to propagate, you'd need the following to be true:
machines would need to be members of domains with at least one-way trust between each other (they don't necessarily have to be members of the same domain).
use domain accounts - not local machine accounts - would look something like domainname\userid. A special case is the Network Service account which has a proxy account in the domain scenario - domainname\machinename$.
How do you tell if your machine is a member of the domain? It's pretty easy if you've got interactive login to the machines. There are a few strategies
interactively the System control panel will show workgroup or domain membership. (Right-click properties on Computer in the start menu)
at the command-line, IPCONFIG /ALL will also show the default DNS prefix which is typically the same as your domain name.
I suspect your ISP would create a domain just to make it easy to manage and monitor their machines. Whether they'd let you create domain accounts is a different question.
You XYZ accounts seem to have same passwords on both machines, and they are not a part of a domain.
WebServer sends just XYZ as a username and answers all password challenges successfuly, as the passwords do match.
DbServer, of course, thinks of you as of DbServer/XYZ, as it knows of no others.
Exactly same thing happens when you try to access one standalone machine from another one over SMB. If your usernames and password match, you succeed.