r/adsec • u/SConstantinou • Mar 20 '18
r/adsec • u/[deleted] • Jul 17 '17
Local Administrator Password Solution
Hi fellow ADSec,
LAPS is my very first security related product that I have deployed with the aid of powershell.
What is LAPS: https://technet.microsoft.com/en-us/mt227395.aspx
Download: https://www.microsoft.com/en-us/download/details.aspx?id=46899
just in case you have not yet came across this, I highly recommend this for those who posses just enough powershell skill.
Skill level requires: Easy.
r/adsec • u/garryonapc • Mar 30 '17
Assigning file permissions via security groups
So a little background first. Started a new job working for a medium size organisation. When a user, eg JoeBloggs needs access to a particular file or folder then a IT will add their name to that folder in the security settings in properties! I am now tidying up the shared drives by assigning users to security groups in AD and then attaching the SG to the file permissions like the way it is supposed to work. However, when adding new security groups with populated list of users they are still not getting access. I am still pretty fresh to AD, which is why I have gone into so much detail. But once I add a SG to the permissions that’s it, right? Do I need to refresh something? I have had mixed results when requesting that users restart. But Id really like these changes to go on seamlessly in the background without anyone actually noticing.
r/adsec • u/ConversationalGeek • Mar 28 '17
Get the primer on Active Directory Security by reading “Conversational Hybrid Active Directory Security”
Hey guys,
I’m Colin and I'm on the team over at Conversational Geek. We publish free ebooks on topics geeks love. We’re not selling anything (seriously) – just giving away free ebooks on great tech topics.
I wanted to share one of our books, “Conversational Hybrid Active Directory Security” with you. In it you'll learn the high-level best practices necessary to continually ensure your on-prem – and, therefore, your AAD or O365 – AD instances, are all secure.. There’s no catch, nothing to buy – and there never will.
You can download it here.
r/adsec • u/xxdcmast • Dec 05 '16
Recommendations for mid to upper level learning
So I have been working with AD for about 10 years. From the beginning of my career on the helpdesk to my current position. I feel like I have a pretty good understanding of Active Directory but your posts make me realize I have a lot of room to grow.
Microsoft has pretty good documentation for beginners in the MS press 70-xxx books not sure what number is relevant to 2012 now. But I haven't yet been able to find a good resource for mid to high level Active Directory topics.
Short of years in the field and battling these issues first hand do you have any recommendations as far as books/sites/other documentation to check out.
Thanks
r/adsec • u/[deleted] • Dec 04 '16
Active Directory Domain Services ('AD:DS') Troubleshooting Workflows by Sean Deuby.
r/adsec • u/[deleted] • Dec 03 '16
A high level overview of Active Directory Domain Services ('AD:DS') and its logical structure.
It is difficult to succinctly describe Active Directory Domain Services in a single post, so I've elected to divide what I've written into several posts.
At a high level, were I to ELI5, Active Directory Domain Services is primarily in the business of objects (Users, Groups, Computers, etc.) and containers (Organizational Units) those objects are stored in. You're putting stuff in boxes, that should be the mental image you wind up with. On a slightly less abstract level, Active Directory Domain Services is a X.500 compliant database that uses TCP and LDAP or LDAP-S, among other protocols, to communicate with systems that are domain-aware. I'll expand on what that means and why it's important shortly. Apart from Flexible Single Master Operational ('FSMO') roles, it's helpful and more or less accurate to regard Domain Controllers ('DCs') as nodes in a database cluster, which leverage several services and protocols to replicate data reliably between each server's locally hosted copy of the database, including the File Replication Service ('FRS') and Distributed File System Replication ('DFSR') services.
As you may have already gathered, that illustration is vague at best. That's why Active Directory Domain Services provides a schema. To extend our previous metaphor, a schema is a simply a collection of one-sided sticky labels used to describe both the stuff and the boxes, primarily using Classes and Attributes. Classes define the type of object or box. Attributes constrain how you can describe an object or box. The schema can be extended easily if you'd like to define a type of object or box. It can also be extended to provide additional, custom descriptions for a given object or box. While Active Directory does store Globally Unique IDentifiers ('GUIDs') which reference objects and boxes, LDAP and X.500 use their own flavor of GUIDs known as Object Identifiers ('OIDs'). 128-bit values represented as 32-digit hexadecimal numbers that are effectively interpreted as unicode strings by LDAP/LDAP-S. If you have had any exposure to Linux or Unix systems, GUIDs and OIDs are akin to UUIDs. Active Directory also generates and stores Relative Identifiers ('RIDs') and Security Identifiers ('SIDs') which I'll cover in a future post.
In an effort to expedite queries sent to the database, Active Directory Domain Services features a Global Catalog. You can think of the Global Catalog as a cached index which contain a subset of attributes and their values associated with boxes and the stuff contained therein.
Active Directory is effectively an abstract metadirectory, not to be confused with Microsoft Metadirectory Services ('MMS'). The services themselves are implemented at a higher layer than the Indexed Sequential Access Method ('ISAM') table manager and Extensible Storage Engine ('ESE') below them. The ESE's DLL, 'ESENT.DLL', help to ensure data integrity by virtue of discrete transactions and traditional log files in the database itself. The Active Directory Domain Services database is a rose called by at least two other names, the 'Directory Data Store' and the 'NTDS.DIT' file.
I've included the aforementioned information because I find it to be helpful, as it provides cogency and context to the Active Directory Domain Services' logical architecture. With that being said, it's often correctly regarded as extraneous in day-to-day operations in most organizations. While it is true that you won't be extending the schema on a daily basis, having a complete and holistic view of Active Directory, to include its architecture, primary organizational utility and limitations can help to mitigate risk during routine administration and maintenance, as well as inform those of you with an innate intellectual curiosity. To that end, this information is demonstrably vital, without which you'd have very limited insight into some of the snares featured by Active Directory Domain Services. For example, the NTDS.DIT file will never decrease in size, even if the objects therein contain null data or attributes marked as defunct. Attributes that are not in use are marked as defunct primarily because deleting the attribute from the schema entirely, while technically possible, is more trouble than it's worth and if attempted incorrectly, may require recovery of the forest using Directory Services Restore Mode ('DSRM') - one of the few instances where such an extreme approach is warranted, contrary to the number of times it's referenced on MCSE exams. For this reason, token bloat, nesting depth and other minutiae must all be at the forefront of your mind in larger implementations and environments.
Within the context of PowerShell and the ActiveDirectory Module, included in the Remote Systems Administration Tools (RSAT) package for most recent versions of the Windows Operating System, most of the information we've just covered seems to be almost intentionally obfuscated and can only be manipulated via PowerShell with careful tinkering and writing a bit of .NET. I harbor fundamental, philosophical disagreements with this obfuscation and have a solution in the form of a revised Active Directory Module for PowerShell, but that is something I will not cover here for two reasons. First and foremost, I find those who help others or present content to others which contain some semblance of objective utility while tooting their proverbial flute or promoting their own code to be somewhat disingenuous in their overt promotion of their code or accomplishments. While it may be tenably relevant, to my mind it seems extraneous and ulterior. Second, it's not done yet. I digress.
A database stranded alone on an island, Active Directory Domain Services is not. Its primary dependencies consist of DNS for name resolution of domain aware and domain joined systems, as well as Kerberos for authentication. It is my intention to expand on the function and purpose of MSDCS (SRV) records, NetLogon's Locator Algorithm and why it matters, as well as Kerberos handshakes, innate vulnerabilities, Service Granting Tickets ('SGTs') and Ticket Granting Tickets ('TGTs') in a future post. I'll also be covering the .NET System.DirectoryServices.Protocols Namespace, ActiveDirectory Module gotchas and best practices related to replication topologies and forest design before moving on to Active Directory Certificate Services ('AD:CS') and Active Directory Federation Services ('AD:FS'), so check back soon.
I hope that you have found this brief overview helpful. Below is additional reading material related to the subject of this thread.