- Thu, Aug 31 2017 at 2:11 am #240999
Been testing JEA a bit and very impressed with the tech, and the introduction on this ms page was pretty good
also I’ve been browsing here, but it’s not much more extensive
I can’t really find much information about detailed stuff though, I was wondering if someone has better in-depth resources.
What I’m wondering most about is the implications of different VisibleProvider settings and secondly a more specific issue : if i want to know the connecting user’s profile paths or even the username – how would I do this in a JEA session that’s running under a virtual account in nolanguage mode?
- This topic was modified 3 weeks, 2 days ago by Michael Pietroforte. Reason: Edited title
- Thu, Aug 31 2017 at 3:31 am #241001
- Sat, Sep 2 2017 at 3:27 am #243718
- Sun, Sep 3 2017 at 11:45 pm #243766
Thanks for the reply, yes I’ve read the series but I think it doesn’t significantly differ from the thin Microsoft documentation out there.
I think the user profile use case probably hasn’t been thought about, at least I can’t see any variables in the JEA session being populated with information about the connecting user. You could achieve this e.g by passing username as a parameter to a JEA session (with sanity checks?) or then you could match it from the transcripts (by transcript PID and envvar PID e.g) or from windows event logs but these are all kinda sub-optimal.
Other thing that bugs me a little is that I can’t find that it logs the ip address of the connecting user either in the event logs or in the transcript files.
It seems to me it’s a good tech, but still a bit rough around the edges, could use documentation and maybe some polishing features. Sounds good that they’ve the idea of bringing it to core though!
- Tue, Sep 5 2017 at 1:36 am #245171
I don’t understand what you want to do with a user profile? The idea is to set up constrained endpoints for certain admin groups such as DNS admins and DC admins. You then put the cmdlets that those groups need in the endpoints and make sure that they can’t establish a normal PowerShell session. Those admins connect through PowerShell remoting to these machines. They don’t need their user profile on the remote machines.
A constrained session is just a PowerShell session where certain cmdlets have been stripped off. So can you access any information as in an unrestricted session if you make sure that the corresponding cmdlets are available in the restricted session.
More details of how you can configure constrained PowerShell sessions:
- PowerShell Remoting without administrator rights
- Restricting the rights of PowerShell users with a constrained session configuration
- Constrained PowerShell endpoints – Visible cmdlets, session types, and language modes
You can log essentially anything with a startup script of the remote session configuration. More info about logging with PowerShell can be found here:
- Tue, Sep 5 2017 at 2:22 am #245175
I can think of use cases where you want the elevated process to handle user e.g created files, and without modifying filesystem rights or providing a shared instead of private folder the only sane place to have the user place them is the profile folder. Also you might want to provide the elevated process with username information in other contexts (say i want to rights (to the filesystem, dcom or anything?) to the connecting user for instance?).
It’s not as if it’s a new problem per se that administrative processes run in a different user context, just something that I think should be a lot more easily solved in PS remoting as compared to some other remote management solutions and also without compromising security and this would provide the system with a lot more flexibility.
I guess many things can be logged and anything can be scripted, logging the connecting ip address is just something I’d expect to be built in since it’s kind of basic stuff and all of this is supposed to be about added security.
- Tue, Sep 5 2017 at 4:17 am #245188
It is hard to understand what you are trying to accomplish.
I don’t see a connection between the user profile and the user rights. If you want an admin to make filesystem changes, you make sure that the corresponding cmdlets are in the endpoint and that he has the rights to modify the corresponding folders. After the user logs in via Enter-PSSession he in his user profile folder where he can create private files.
By default, logon events are logged in the Security event log. You can also see PowerShell remoting logon events there.
- Tue, Sep 5 2017 at 4:59 am #245193
I don’t really have such a specific problem tbh, but I’m certain there are use cases for extending the user context to the JEA session for many purposes as per the whole JEA philosophy.
I checked the event logs and yes you can see which users log in, but not from which ip address. The only place where I found this information (and yes I needed to dig a while) was using the get-wsmaninstance cmdlet. It’s not visible in e.g. get-pssession. In my opinion having to dig so deeply for this information is kinda stupid.
You must be logged in to reply to this topic.