How to restrict access to salesforce application for the time users are on leave on basis of Leave start and end date?
Freeze user on leave start date and then unfreeze on leave end date ?
Any other automation approach ?
What exactly you want to achieve? Nightly batch job that does either of these should be enough? Not sure if you can do time-basrd workflows/processes on users.
You can (de)activate them although it's bit of a nuclear option. Other users might be impacted when they work with deactivated users' data, "operation was performed with inactive user" error.
You can (un)freeze manually or by modifying UserLogin table, each user will have 1 record in it. https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_objects_userlogin.htm
If you want them to be able to log in but do limited set of things - you could look at your sharing rules and temp change their role/group/whatever. Or change profile to read-only. Or unassign a permission set.
Then there are more sophisticated things like maybe disabling their SSO, having a login flow that checks something on user record, checking up addresses (like allow login only from office network, not from home). You could look into "high assurance sessions", multi factor authentication (take their work phone or RSA device when they go on holidays?) or there's interesting trailhead about detecting / preventing suspicious activity. https://trailhead.salesforce.com/content/learn/modules/enhanced_transaction_security and https://trailhead.salesforce.com/en/content/learn/modules/event_monitoring
Related
I found this thread and this thread, but haven't found a solution I can understand. I'm building a winforms desktop application that I hope to install on a few machines that query a database on a network drive. My goal was to make a table with usernames and a boolean that changes to 'true' when the user signs into the app. My intent was to prevent the same user from signing in on two machines at once. However, it occurred to me that an app crash or loss of power would prevent any code I could write from updating the datatable table column to 'false'. I'm a novice-intermediate programmer, not a professional, and I haven't found a solution so please forgive me. All suggestions would be appreciated. Some suggestions I have found are creating a table with sign-in and sign-out timestamps and to compare the time between them at startup, using session IDs (which I'm not sure how to do), and attempting to catch crashes to trigger some code. The problem is I'm not sure if there's a consensus on what the proper way is to accomplish what I'm trying to do, which is to prevent duplicate logins and also logging out users automatically in the event of some system failure so that they can login again later.
I'm a programmer who is about to release an intranet site where apprentices can rate their educators and vice versa. Currently the system is working as planned, however HR wants some way to verify that the users are OK with their ratings. If not, they should be able to unlock their ratings so that the other person has to re-do the rating.
Unfortunately, HR also wants to reduce the amount of logins that these users have to endure. In the worst case scenario, users have to:
Log in to rate the educator/apprentice
Log in to unlock the rating
Log in to rate the educator/apprentice again
And so on...
The user who fills the rating has to be user A, while the user who unlocks or confirms the rating has to be user B. User A can also unlock the rating if they have a correction.
This process has to be done twice - once for the educator, once for the apprentice.
There is usually only one workstation present (factory environment).
Possible solution:
My suggestion is a kind of meeting workflow. One user logs in, clicks a button in the appraisal and the workflow starts. The other user is prompted to log in. This starts a kind of "double session" with both users logged in at the same time. This is a way to verify that both of them are present in a meeting.
This process could be used for multiple ratings at the same time, guiding the users through the process one by one.
HR wants both of them to meet and discuss their ratings.
Are there any security and/or best practice concerns that I should be aware of? The system has to be ready on the first of August, so I'm really hoping to solve this issue as easily as possible. Are there better ways to do this?
It turns out that my idea of logging in two users at the same time wasn't so bad. At first, a regular user logs in and launches the meeting mode. In order to verify that the other user is present, this second user logs in. Both user's data is now stored in the session and the meeting workflow launches, guiding both of them through their appraisals. When the last appraisal is finished, the second user is logged out.
This question is solved.
We don’t have wi-fi in every area of our outdoor facilities. So, we have the need for users to work with data sets disconnected and then sync back up. Our thought is to have the user’s PC poll for wi-fi every 60 seconds. If it sees it, it connects and uploads/downloads data.
So let’s say a user’s PC grabs a data set and goes off and works locally with it (inserts/updates/deletes). Meanwhile, someone else is inserting/updating/deleting the same data set directly in the database (someone back in the office). How then, can we rectify everything?
E.g. if record “1” has a value of “blue” and the user downloads it locally. It then changes “blue” to “red” while offline. Once wi-fi is found, it could just update, but if an office user had changed “blue” to “green” it might be a bad thing. “Last one wins” I suppose could get us in trouble.. especially if the offline user inserts a record not realizing that the office user has as well.
This question really isn't how to do something technically. I suppose it's more about looking for a best practice.
Thanks for any feedback.
You dont have to reinvent the wheel, there is already a tools to synchronize database e.g symmetricds to facilitate data synchronize for inserts/updates/deletes operations.
I'm developing an app that has to get some information from various sources (APIs and RSS) and display it to the user in near real-time.
What's the best way to get it:
1.Have a cron job to update them all accounts every 12h, and when a user is requesting one, update that account, save it to the DB and show it to the user?
2.Have a cron job to update them all accounts every 6h, and when a user is requesting one, update the account and showing it to the user without saving it to the DB?
What's the best way to get it? What's faster? And what's the most scallable?
12h or 6h, you have to do the math your self, you are the only one to know how many sources, how is your app hosted, what bandwidth you have....
Have a look at http://developmentseed.org/portfolio/managing-news it is drupal based and does what you need (and much more). You can either use it or diving in the code and see how it is done.
I'm using LastLogonTimeStamp property of user in Active Directory to get the Last logon date time, Value isn't consistent,
Any one else faced same issue?
Can we trust the LastLogonTimeStamp?
Update:
It's just one Domain Controller
http://www.microsoft.com/technet/scriptcenter/topics/win2003/lastlogon.mspx
You would only use lastLogonTimeStamp if you have alot of domain controllers and don't need the most accurate results. With a single domain controller use the lastLogon attribute.
LastLogonTimeStamp by design only gets updated when the user logs in and the current value is between 9 and 14 days old. They did this to cut down on replication traffic in AD.
This blog posting says it well:
It is important to note that the
intended purpose of the
lastLogontimeStamp attribute to help
identify inactive computer and user
accounts. The lastLogon attribute is
not designed to provide real time
logon information. With default
settings in place the
lastLogontimeStamp will be 9-14 days
behind the current date.
If you want the real last logon information for a user, you have to pull the lastLogon attribute from each domain controller in the domain and use the most recent value.
Do you have a network with several DC (domain controllers)? They might be out of sync since the LastLogonTimeStamp will be updated on the DC that the user actually logs on, and synchronization might take some time.
Marc
If you ever plan to have more than one DC, then LastLogonTimeStamp may not a reliable method for determining something like whether or not an account has grown "stale", since that attribute is not replicated to other DCs in many (most?) scenarios, depending on your domain functional level.
A better method for determining this is to look at "password age" (via the PasswordLastChanged attribute). For example, if someone hasn't reset their password a week or two after it has expired (or some other time span depending on your particular environment), then there is a good chance that you have an orphaned account there.
You can't get an user's True LastLogon time neither by lastlogon or lastlogontimestamp in straight way..you need to do some custom work to get latest logon time.
By LastLogon
You need query lastlogon value from all the domain controllers and compare all values then get the highest logon time as True Last Logon
By LastLogonTimeStamp
Since it would be the replicable attribute you can query from only one DC but it will not give accurate result, it has precision around 14 days depends upon the attribute msDS-LogonTimeSyncInterval.
If you want the real last logon information for a user, you have to pull the lastLogon attribute from each domain controller in the domain and use the most recent value.
Unfortunately this isn't completely accurate. I have used the lastlogon attribute and while it IS fairly close for most user accounts I've tested with this, I've come across many that return a date in 1600, and those that are close show at times that I know for certain the specified users weren't even able to login, for instance my own LastLogon showed at 7:50am when I know I signed in at 8:15am.
Many admins seem to sometimes desire to use this information to verify compliance with company policy. Unfortunately Microsoft seems to have disregarded such intentions by design for system functionality purposes.