I know I’m not alone on this one. I travel a lot, and I always hated when my password expired while I was traveling, but I wasn’t notified. Sure, there is a notification built into Windows, but that only shows up as a pop-up on your computer when you’re logged in to the corporate network. What about road warriors who use a VPN or remote applications? It’s very frustrating when passwords expire and you’re in a remote location.
To eliminate this problem, why not help users out by giving them notifications through other means, not just a pop-up on their computer? We can do that! Our solution gives you two of the best possible options for mobile, or even in-house, users.
User accounts that were created yet the user never logged in – such user accounts are a significant security issue for all Active Directory environments. You can read more details about this security issue here.
Given the security risk posed by these user accounts, how do we address that risk? Ideally, we would want an automated system to help out. There is a solution, which is automated! The solution is ADManager Plus.
In order to automate a solution to address the problem, we need to consider the following parameters:
- Obtaining a list of user accounts that have never had a user log in.
- Obtaining the “when created date” for each user account obtained in parameter 1.
- Determining the length of time that is ac
Nearly every Active Directory database has at least one – a user account that was created, but the user never logged in. The reasons why the user never logged are plentiful, but the fact the user account was not addressed is still an issue. Why are user accounts that have not logged in an issue, you may be asking? Well, let’s go over some common configurations at user account creation time:
- User accounts are created hours, sometimes days, before the employees start work.
- All new user accounts are granted the same password at creation.
- User accounts are added to all of the necessary groups, to allow immediate access to resources.
Considering all of these configurations, you should realize that you have user ac…
It is 8am Monday morning. You, the Active Directory administrator, receive a stack of papers for the new employees of the week. You proceed to create the 12 new users. You proceed to ensure the first name, last name, and logon names are correct. You also input the password for new users, which is NewHire01. After you create all 12 user accounts, you proceed to configure the details for each account, including group membership, home drive, telephone number, and department.
You complete the task by 8:20am and move on to the rest of your day. You have done this every week for the past 10 years and think nothing of the “setup” you just created for the disgruntled employee that is working in the engineering departm…
There are hundreds, if not thousands, of possible settings related to Active Directory, including group membership, user rights, access control lists (ACLs), delegations, and so many more. With all of these settings, there are always some settings missed or misconfigured. Here are three security-related settings that I have found most Active Directory environments fail to have set up correctly.
Enterprise Admins group: For most Active Directory installations and corporations, the Enterprise Admins group should be empty. This group should be empty because the group capabilities are rarely utilized, but having a user in the group exposes that user account to attacks and the dangerous use of the group
There is nothing scarier to an Active Directory administrator than the thought of someone attacking the domain controllers. The majority of attacks come from within the internal network and come from existing domain users. If the attacker does not have elevated credentials, the goal for the attacker is to try to obtain these credentials. The typical method for this is to guess passwords of existing users.
When an attacker tries to guess the password of another user, there will inevitably be failures – at least, we hope so! A high, repetitive number of failed logons for a single account can indicate a potential attack. The key is finding these failed logons before the attacker is successful, so you can neg…
Well, I know I have been saying it for years, talking about it like it was one of the most important aspects of your computer, and emphasizing it as one of the top five most important security configurations for corporations and users.
With so many companies being attacked, compromised, and making front page news, I hope that now you get the picture!? The passwords for your Active Directory, your bank, Amazon, LinkedIn, and other sensitive accounts are key to your career, personal protection, and economic stability.
Now, all I can say is, “I told you so!” Just like your mom said to you regarding washing behind your ears, wearing clean underwear, and not cursing in public.
It only makes sense, does it not…
Every Active Directory installation has one common issue. Every installation has one or more users that were created for a project, new employee, returning employee, and the like; but the user account was never used. These users should be cleaned up as they pose a threat to the overall security of the environment.
I know, “pose an overall threat to the environment” seems a bit severe. However, I truly believe this, and these are the reasons why:
- Most organizations use the same password for new user accounts, knowing the user will be forced to change the password on next logon. However, if the user account was never used, it could be used as an attack account at any time.
- Most organizations place new user acco
Before getting into the specifics, I would like to give a small introduction on tracking Logon / Logoff in Active Directory environment, which is a cumbersome process.
Auditing the Windows Active Directory environment
With the current Windows architecture it’s difficult to get all logon data at a single point. In an AD environment, a Domain Controller (DC) is the one which does the real authentication. When there are multiple DCs in a setup, handling the authentication mechanism, the logon data (please note only the logon data) is available in different computers (read as DCs). So to compute a clear logon activity collecting all these data is essential. Also another pain point here is …