I have a Linux server using Kerberos for user authentication, and AFS for user homes. When I log into the machine with a forwardable Kerberos ticket, (I suppose) PAM takes care of my AFS authentication too, so I automatically get access to my AFS home after login.
Let's say I log in, and I create a screen session and start an application in it. Then I detach my screen session, and log out from the machine. My Kerberos ticket gets dropped automatically, so my screen session running in the background and the application running in it doesn't have access to my AFS home anymore. This is normal, and it's good as it is.
Next time when I log into the machine, how can I "provide" my already running screen session and the application running in it (the processes themselves) with a new Kerberos ticket and make it able to access my AFS home again without having to restart it?
You should be able to attach to the screen session, create a new window/'screen' inside of it (with the default config, you can do this by pressing C-a C-c), and just run kinit && aklog. You do not need to run this "inside" the existing running applications or anything like that; you just need to run it somewhere within the same screen session. After that, you can detach the screen and logout, and the screen session should still have your credentials (until they expire; you can use krenew to keep them going for a big longer, but not forever).
A more detailed explanation of what's going on, if you want to know. I'm assuming you are logging in via ssh and PAM is being used, but the same general process works for other setups, as well:
When you first login, PAM assigns you a PAG (a kind of container for your AFS tokens), and runs something that is somewhat equivalent to kinit and aklog to give you AFS tokens inside that PAG. Your shell is then run inside that PAG, so everything that you run in that shell is associated with that PAG and its credentials. That includes the screen session you created.
When you logout, the PAM configuration says to destroy your credentials, which means it destroys the AFS tokens associated with that PAG. That's why the screen session loses credentials and loses access to your home directory: the tokens for that PAG have been destroyed.
Later on, if you login again, you're assigned a new separate PAG, and again you get AFS tokens. The old screen session is still associated with the other PAG, the one where the tokens are destroyed. So if you attach to that screen session, and run kinit and aklog somewhere inside of it, that will create new tokens that are associated with the old PAG from the first time you logged in. You can then detach from the screen session and logout, and the tokens in your current PAG will be destroyed. But the PAG for the screen session is untouched, since neither PAM nor anything else knows about that PAG anymore. So the tokens for it will continue to be valid until they expire.
The "right" answer is to use something like krenew or kstart to monitor your
screen session and make sure it has a valid tgt and afs token. Most sites will allow you to renew your ticket for up to 7 days.
However, that's not the question you asked. The ticket part is easy. The environmental variable KRB5CCNAME stores the location of your kerberos ticket.
Generally it looks something like this
KRB5CCNAME=FILE:/tmp/krb5cc_7472_lIwDv27056
So poke around in the /proc system and find the value of KRB5CCNAME for your screen process and copy your existing ticket to that file location.
The AFS token part is much trickier, if you can get the screen process to somehow run aklog after you copy the ticket, that is the most straightforward
solution.
There are tools for extracting and setting tokens. gettoken and settoken, but I know of no straightforward way to use them to set the token for an arbitrary process. AFS tokens are stored as part of the process data in the kernel. That's why you see the funny high numbered groups when you use the groups command on a machine using AFS.
Related
I've an Access application located on a server with backend tables.
The application recorded the users sessions; login if they started the app & logout if they closed it.
Sometimes the user lost the connectivity with the server and the application been restarted, the user remains login on the previous session because recording logout from a normal exit not occurred.
Is there a way to check on the backend file if a user is disconnected to record him as "signed out"?
I think your referring to the *.laccdb file that access creates when someone is logged in to the BackEnd table.
Usually if it does list the same PC twice, once all PCs eventually logs out of the BE the *.laccdb should disappear if not, you can delete this file manually however, if the user looses connection ie the VPN goes down and doesnt log back in, then the BE will show that the PC is connected, in this case usually you can delete the *.laccdb.
If at any time you can not delete *.laccdb file Ask the user with the listed PC to log out. Worst Case if a user is not logged in but the *.laccdb exists the listed PC needs to reconnect and disconnect cleanly.
If the FE needs to check for connection to the BE it can be done but will not solve your issue, if the users PC crashed or VPN goes down whilst in the application then there very little that can be done because its too late, the damage is already done.
Good day.
I am developing a program that will be used in a corporate environment by the end users. The application will automatically fix certain errors as soon as the user selects the application name, chooses the symptom or error message and clicking on the fix button.
The idea behind is to decrease the amount of calls we receive at the IT Service Desk (The company's personal Call Centre for IT Issues) and at the same time assist the end user by resolving the issue within a minute (versus waiting on the phone for up to 15 minutes or more).
I've am not yet allowed to upload an image of the application, but imagine a small'ish windows form with 2 columns; Aplication name and Synptom. The user will choose the application's name, click on the error message and click on the FIX button. This basically automates whatever we has IT Techs would manually.
The problem I'm facing is that some of the code is supposed to be executed with adminsitartor rights, eg. Stop and Start a given service, adding regsitry entries for Local Machine, etc.
Given the fact that none of the users will be allowed to have elevated rights and the fact that they need to use this application as a sort of "self-help" alternative without the need to call the IT Service Desk, is there a way to give a set of code "administrator permissions"? The application should NOT request the user to enter ANY passwords.
Regards,
Willem
No way, AFAIK: the model in common operating systems is process-centric, so that the process is given permissions that are then inherited by its code. You can elevate such privileges at some point, but that will be for the whole future life of the process (or as long as the authentication token for it ceases to be valid).
In windows the right way to do that is to employ a back-end service: at boot, you start the service called IT_Auto_Fixer_Back_End with high permissions (try to avoid Administrator, NetworkService or LocalService could be enough for you). When the app IT_Auto_Fixer_Front_End is started with USER privileges, it operates until it needs something with high privileges. At that point it sends a request to the service, that will do it.
If you choose this way, some important advices:
The IT_Auto_Fixer_Back_End must not become a backdoor! If you use TCP as form of communication with IT_Auto_Fixer_Front_End, make it listen localhost only and use SSL (yes!) to encrypt local traffic
It must not be possible to invoke arbitrary commands using IT_Auto_Fixer_Back_End. You need to enumerate the possible requests that could be made (i.e. a command like stop_mysql_service rather than accepting directly the string net stop mysql - the application logic will translate your string into the real OS command)
Every input from the user could be used to perform command injection. To prevent this, use the Windows API that requires an array for the command - this way if the user adds options to a command (i.e. the name of the service in net stop) they won't be interpreted as another command (common scenario: when accepting the name of the service as a parameter, a malicious user that tries to execute something like net start mysql ; net user /add hacker t00E4sy). Authentication and encryption will not help you against this, you must escape any user input that goes inside the command.
Sanitize your ENVIRONMENT by using the API that executes commands setting the PATH (and other relevant variables), so that the user will not be able to taint the PATH, executing C:\temp\net.exe instead of C:\Windows\System32\Net.exe
IT_Auto_Fixer_Back_End service should be authenticated: it should check every time if the request comes form the user by checking if the Kerberos token is valid (Windows => you get a very nice Kerberos environment for free!). This will prevent someone else to break into the machine, use SSL to connect to the localhost port and elevate privileges through your service
The above (authentication) still stands when something else (i.e. shared memory, windows sockets, a file, etc...) is used as communication channel between IT_Auto_Fixer_Back_End and IT_Auto_Fixer_Front_End
Life gets harder when you want to properly implement something dealing with multiple level of permissions...
Something happened on my development workstation (Windows 8.1) in the last few weeks which require me to either run my App Pools with the "Load User Profile" setting at False or not run with the identity set to ApplicationPoolIdentity. If I were to create a new app pool, using ApplicationPoolIdentity as the identity and with loadUserProfile=true, the following happens when trying to load the application in a browser:
A number of errors in the Windows Event Log (both System and Application types):
Warning event 1509 - Windows cannot copy file \\?\C:\Users\Default\AppData\Local\Microsoft\VSCommon\12.0\SQM\sqmdata-7236-039-00000.sqm to location \\?\C:\Users\[Name of App Pool]\AppData\Local\Microsoft\VSCommon\12.0\SQM\sqmdata-7236-039-00000.sqm. This error may be caused by network problems or insufficient security rights.
Error event 1511 - Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.
Another 1509 warning
Error event 1500 - Windows cannot log you on because your profile cannot be loaded. Check that you are connected to the network, and that your network is functioning correctly. DETAIL - Only part of a ReadProcessMemory or WriteProcessMemory request was completed.
5 x event 5022 warnings - The Windows Process Activation Service failed to create a worker process for the application pool '[App Pool Name]'. The data field contains the error number.
Finally an error 5002 - Application pool '[App Pool Name]' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
The App Pool is shut down, as the error 5002 said
"HTTP Error 503. The service is unavailable." is then seen in the browser. Any further requests are met with the same (which makes sense since the app pool is shut off).
I've seen a common "fix" for this here and here which basically say to turn off profile loading. Yes it makes the problem go away, but this doesn't get to the root cause. I know that it is possible to run with this configuration as a I have a Windows 2012 machine which supports the configuration just fine. In this case, hitting an app with a new app pool set to ApplicationPoolIdentity and loadUserProfile=true actually creates the new user profile (I can watch as the profiles folder is created in C:\Users) and the app runs merrily. What's worse is I know this configuration worked on the problem machine just a few weeks ago. I have a number of App Pools I created which have their own profiles and folder under the C:\Users folder. These app pools work just fine NOW with the ApplicationPoolIdentity and loadUserProfile=true settings. It's just that NEW app pools refuse to run and load a user profile.
Does anyone have any insight to what might be going on?
Edit: I read the bottom of this recent article. It's a bit contradictory in saying that the setting can be turned on, but also says:
Only the standard application pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new application pool.
However, if you want, you can configure IIS application pools to load the user profile by setting the LoadUserProfile attribute to "true".
I'm very confused.
The SQM file listed in the event log warning was created by a Windows or Visual Studio update. When the user profile service or application pool runs and tries to create a new profile, it tries to copy the file to the profile. The SQM file requires administrator permissions to copy. The user profile service or application pool does not have sufficient permissions to copy the file, an error is generated, and the user profile is not created. Without a user profile, the application pool cannot run because it doesn't have an isolated secure place to store data.
Remove or delete the SQM file from the source directory, and the user profile will be created successfully when the app pool is initialized. You can also change the permissions on the SQM file, but I'm not sure what the appropriate permissions should be. The user profile service runs as "LocalSystem Account". See its documentation for permission info. It's unclear to me whether the application pool identity itself is being used to perform the copy operation, or the local system account.
If you remove the file from the source directory, you could also manually copy the file where it was trying to go as well.
After a very brief search about what SQM is, it seems like it is traditionally used as "service quality management". Usually it would contain information to send back to the program authors with metrics, logs, or somesuch. I don't know if this is the case with this file or not. So it doesn't seem like it's important to include it in the new profile.
I can't take 100% credit for this answer, as I was tipped off by a comment attached to an answer on some other question. I can't find the link to it in the 50 browser tabs open for troubleshooting this. That guy deserves a thank you, because I believe this is a much better solution than compromising the security of a server by pooling all the resources together like in IIS 6.
P.S. As noted in your comment, a bug report has been filed.
I need to monitor other accounts on a Windows Server, and have figured out that to do so, I have to be able to run a monitoring process on them. The main program runs from a full-access (possibly NT_AUTHORITY) account, but all ways of starting processes seem to require the user password! help please!
You could create this as a service instead and when installed supply password for the service properties (which user you want to run it as). Then the need to re-enter password should disappear.
Using Windows 2003, I'm look for a way to create a "logoff script" that will continue with the current logoff then immediately login another user. So, "UserA" logs off. Script fires to login "UserB".
This is part of an application upgrade for a computer where we have written the 'shell'; similar to a kiosk application. For the upgrade we need to logon as 'Adminstrator' then, when the upgrade has completed, logoff 'Administrator' and logon as 'sample_user'. We would like to accomplish this WITHOUT rebooting.
Note, I do not want a script that will initiate the logoff (i.e. "shutdown"). I'm looking for a script that will run upon the user logging off (set via Group Policies). As above, the script should log a different user on.
Thanks.
Don't think it's possible in the stated way (script at logoff).
You'd have to set the machine to logon automatically as a specified account and then log off (having it log on automatically for you) and then you'd have to disable that feature again afterwards, by placing a temporary logon script... generally sounds messy.
The actual setting can be made using tools like Microsofts Shared Computer Toolkit or similar (not so sure how the "normal" registry auto-login behaves at manual logout but I've had an XP kiosk that would automatically log on instantly, even if you logged out manually - you had to override it using some key like shift+logoff to be able to manually specify the login again, so somehow it can be made).
The "easiest" way might be to replace msgina.dll with someone of your own making...
But why are you doing this? Just use runas and start whatever you need to do as that other user without logging off the console user - it's a multi-user system afterall? The desktop is just fluff ^^
(This will anyhow require that the user credentials are available to your script, which kind of makes it redundant as you compromise the security of that account - defying the purpose of having that second account in the first place, for whatever purpose it exists?)
I would try setting the registry to autologon with the user you want, and then simply logging off the admin user. That should log your kiosk-user right back on.
Not sure how to login another user once the current user logs off (not sure if windows would let you...)
But you can use shutdown to logoff:
shutdown /?
Here's some ideas that probaly fall into the "cheap hack" category:
How about logging in at UserB in the first place, and then using runas /user:userA <cmd> to run the first part of the install process?
If that's unacceptable, I know there's a way to make Windows workstations (those that aren't part of a Domain) automatically log in into a certain user account after a restart. Perhaps if you looked into which Registry changes happen, and duplicated them, a reboot would automatically log in that user. (Of course, as a final stage, after userB logs in, you would have to revert those changes :-)
It also occurs to me to wonder if perhaps there's a way for a service to force an open "login screen" to log in as a certain user. Maybe using some method like the way the Remote Desktop does it remotely... If that's possible, then you could create a service that you install before logoff of userA, that would trigger the login of userB.
You can script it with VNC (there are many free versions, take your pick). Set up a VNC server process on the machine to listen on localhost. When the user logs off, your logoff script will connect to the machine using VNC and send the keystrokes necessary to log on the next user. VNC uses the RFB (remote framebuffer) protocol; there are libraries for most popular languages, so you should be able to get something working quickly. Or there are related tools that might help.
If you were to run something like this as a normal script in a given language, it would most likely not work as when you log out of your account, all processes should be killed along with your running script.
You might be able to create some sort of 'service' that would run on a service account (i.e. always active) that would automatically do this user switching for you.
My bets are on Windows Powershell, although I'm not entirely sure what functionality it has as far as actually creating a service.
A quick search brings up the following (The second link is to a forum but it mentions running Powershell as a service and sending that service a parameter which would be the path to your user switching script)
How to Create a Windows Service using Powershel
Powershell Script as a Windows Service
I don't have a Windows 2003 server or a system with a "Group Policies" setup to test my hunch but you could take a look at SU ("switch user") for Windows. Originally part of the Resource Toolkit this has been extended to a new SUperior SU. Do post the results/script if this works.
You could approach this from the perspective of building a remote control utility (like VNC, etc). The big thing here is that if you want access to the Logon screen (i.e. the CTRL + ALT + DEL / username/password) part, the only kicker is that a Windows Service is the only component that can access this, so you'd have to create one.
The only problem I see with this technique as a whole is that even if you spent a great deal of effort getting it to work (and it would be a pretty big effort), the chances of this working successfully with the whole thing originating from a logoff script (i.e. when stuff is shutting down) are low even due to the number of things that can go wrong when logging back on as Administrator.
Just remember that for anything you need to run as an Administrator, there are easier ways in Windows to make that happen (such as Run As, changing the user permissions on the items that need to update, etc).