• A
    Adam Gordon

    Adam,

    I hope all is well. Mighty TALL order you have tasked me with here, let's see what we can do to whittle this down to a manageable size, shall we?

    I will take them in the order that you asked them in:

    1. What are the forest and domain functional level requirements for each feature of AD FS? Ie.. Device registration, certificate authentication, etc...

    Check out the following to get the Low-Down across the Feature set for ADFS:

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-requirements

    1. What is the default Farm Behavior Level of newly deployed AD FS installs? Does it matter what the existing forest/functional levels are?

    AD DS requirements - This is where it gets CRAZZZZZZZZZZZZY ... :)

    Domain controller requirements:

    AD FS requires Domain controllers running Windows Server 2008 or later.

    At least one Windows Server 2016 domain controller is required for Microsoft Passport for Work.

    Domain functional-level requirements:

    All user account domains and the domain to which the AD FS servers are joined must be operating at the domain functional level of Windows Server 2003 or higher.

    A Windows Server 2008 domain functional level or higher is required for client certificate authentication if the certificate is explicitly mapped to a user's account in AD DS.

    Schema requirements:

    New installations of AD FS 2016 require the Active Directory 2016 schema (minimum version 85).

    Raising the AD FS farm behavior level (FBL) to the 2016 level requires the Active Directory 2016 schema (minimum version 85).

    Service account requirements:

    Any standard domain account can be used as a service account for AD FS. Group Managed Service accounts are also supported. The permissions required at runtime will be added automatically when you configure AD FS.

    Group Managed service accounts require at least one domain controller running Windows Server 2012 or higher. The GMSA must live under the default 'CN=Managed Service Accounts' container.

    Sooooooo... what does all that actually mean?

    Well several things actually, but take a look at the following as, it explains the FBL concept, versioning and how it all comes together:

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server

    If interested in what Server 2019 does to the mix, check out the following:

    https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/whats-new-active-directory-federation-services-windows-server

    1. Is workplace join the same as device registration?

    No. Although a little dated, the following gives you a good overview idea of the differences:

    https://blogs.technet.microsoft.com/trejo/2016/04/09/azure-ad-join-vs-azure-ad-device-registration/

    Hope that helps to put things in perspective and move you in the right direction(s).

    Let me k now if you have any follow up questions.

    Cheers,

    Adam

    posted in Microsoft read more
  • A
    Adam Gordon

    Razmik,

    I hope all is well.

    You are stating that "there are different encrypted data outcomes for the same plain text with the same algorithm (3DES) and the same key"

    While that is possible if the implementation parameters of the cryptosystem change, I am not sure how CryptoDemo implements the crypto functions that you are examining, and as a result, I am unsure whether or not that is expected behavior.

    For instance, if you were to vary the Initialization Vector, if one were being used, then this behavior would be expected. If you were to implement 3DES using different modes, then the behavior may also be possible.

    The short answer to your question is that if you kept EVERYTHING the same in the cryptosystem, then the same plaintext should always produce the same ciphertext, and vice versa, assuming that the same key pair is used for the system at all times.

    The way that you get to the last part of your question statement, " So does that mean that there are infinite number of Crypto texts which could be decrypted to arrive at the same plain text? (assuming same 3DES algorithm and same key)" is that one or more elements of the cryptosystem must change in order to produce the different ciphertext outputs.

    I hope that this helps to clarify.

    Please let me know if I can answer any further questions.

    Cheers,

    Adam

    posted in Security read more
  • A
    Adam Gordon

    Adam,

    I hope all is well. You are on the right track here, and in the right place, but there are two ways to go based on settings on the Data Manager tab, and both could provide an outcome here, depending on your choices:

    To enforce the selected Data Manager options before the DCS starts, you need to select the "Apply Policy Before The Data Collector Set Starts" check box. When you select this option, previous data is deleted based on the configured Data Manager conditions before the DCS creates the next log file.

    ** By default the Data Manager does not act on the selected options until the DCS has completed.

    The available Data Manager conditions are:

    1. Minimum Free Disk The amount of disk space that must be available on the drive where log data is stored. If you select this condition, previous data is deleted according to the Resource Policy that you choose when the limit is reached.

    2. Maximum Folders The number of subfolders that can be in the DCS data directory. If you select this condition, previous data is deleted according to the Resource Policy that you choose when the limit is reached.

    3. Maximum Root Path Size The maximum size of the data directory for the DCS, including all subfolders. If you select this condition, this maximum path size overrides the Minimum Free Disk and Maximum Folders limits, and previous data will be deleted according to the Resource Policy that you choose when the limit is reached.

    Based on items 1 & 3 described/defined above, you would have to be careful not to choose both 1 & 3, as 3 overrides the settings for 1.

    The right way to go would be to set item #1, and deselect item #3.

    In addition, you would have to understand the issue around the choice of the "Apply Policy Before The Data Collector Set Starts" setting, as that would be the only way to ensure that the previous data is cleared to make enough room based on your settings, and would allow the collector to run, WITHOUT violating the minimum space requirement, since the settings are applied prior to start of the collection, not after it finishes.

    I f there was not enough free space available/made available by the deletion of the previous logs, the DCS would not initialize in the first place.

    I do not like questions like this one, as they are not structured and worded to accurately ask about settings as they appear/are able to be implemented, but rather approximate the, and ask you to "estimate" or "extrapolate" meaning and intention as part of your answer, which is not a good way to test your abilities, but rather leads people to guess based on a process of elimination which may or may not be correct.

    I hope that helps. Keep plugging away !!

    Good Luck....

    Cheers,

    Adam

    posted in Microsoft read more
  • A
    Adam Gordon

    Adam,

    I hope all is well. You are right, the Internet is wrong.

    Cheers,

    Adam

    posted in Microsoft read more
  • A
    Adam Gordon

    Razmik,

    I hope all is well. As Adam (the other Adam) has correctly described, Perfect Forward Secrecy is a feature of specific key agreement protocols that gives assurances your session keys will not be compromised even if the private key of the server is compromised. By generating a unique session key for every session a user initiates, even the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key.

    Great question by the way !! & Thank you to Adam Tyler for jumping in with a great answer. :)

    Cheers,

    Adam

    posted in Security read more
  • A
    Adam Gordon

    Razmik,

    I hope all is well. I would not say that either is a subset of the other. SSO is not reliant on Federation, although it can be extended to Federated partners as part of the architecture of a Federation relationship.

    Federation implies the use of SSO ultimately as an outcome of the process of Federation, perhaps as a byproduct, BUT Federation itself is the process of extending trust to an external third party, allowing them to access one or more internal systems as a result of the Federation relationship. Whether they will use SSO to do so is dependent on the choices made as part of the Enterprise Security Architecture of the party extending the offer to Federate in the first place.

    While SSO is ubiquitous today, and would most likely be used in almost any scenario, it is not necessarily the only way to go, and may indeed not be the mechanism chosen for authenticating Federated users under certain circumstances, such as the need to access highly compartmentalized and secured infrastructure.

    Hope that helps.

    Cheers,

    Adam

    posted in Security read more
  • A
    Adam Gordon

    Razmik,

    Great question. Let's discuss … So the operative in your question is the concept of "assuming" that something is kept secure, in your case, the user's name and password.

    The way Token based authentication works, it should provide security for the user's information IF (big IF) nothing were to go wrong, and / or nobody was able to hijack or break the system in any one of several ways that could lead to compromise.

    My point being that while the system is designed to provide a measure or protection, it is never absolute, and rather than assume, we should trust but verify that the system is operating as designed and implemented to ensure maximum protection.

    I hope that helps.

    Cheers,

    Adam

    posted in Security read more
  • A
    Adam Gordon

    Adam,

    I hope all is well. You are correct, you would only need to have membership in the IPAM IP Audit Administrators group.

    See below:

    IPAM IP Audit Administrators: Users who are in the IPAM Users IPAM security group and have the privileges to view IP address audit information.

    IPAM Users: Users who have the privileges to view all information in IPAM data store except the IP address audit information.

    IPAM MSM Administrators: Users who are in the IPAM Users IPAM security group and have the privileges to manage DHCP and DNS server instance-specific information. Such users are Multi Server Management (MSM) Administrators.

    posted in Microsoft read more
  • A
    Adam Gordon

    Razmik,

    I think that it would be more accurate to say that NMAP is a network Scanner and a security auditing tool. It is not a true vulnerability scanner in the sense that it looks for vulnerabilities based on a pre-set list or set of definitions, but rather uses raw IP packets to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics.

    You can use it for taking a network inventory, managing service upgrade schedules, and monitoring host or service uptime.

    Hope that helps.

    Cheers,

    Adam

    posted in Security read more
  • A
    Adam Gordon

    @adam-tyler said in Migrate CA:

    automatically removed when the CA role is uninstalled

    Adam,

    I hope all is well. Great series of questions about ADCS and its operational intricacies. Let's jump in and take care of all those questions....

    Q2: You are spot on with this, as this is the recommended and standard way this is done. There are other options, such as using Powershell to script this activity, (up to you), but it may be more trouble than it is worth.

    I am including a sample script that would allow you to have a sense of what would have to be done, and to play with / start from if you want to explore your options:

    NOTE: You will need to change the template name to whatever you are using in your environment.

    NOTE: Needs powershell V3 or above

    =========================================================================================

    #Get local certificate store
    $my=dir cert:\LocalMachine\My
    
    #Get active certificate using "Domain Controller Authentication" template
    $dccert=$my | where-object {($_.Archived -eq $false) -and (($_.extensions.item("1.3.6.1.4.1.311.21.7").format(0)) -match "Domain Controller Authentication")  }
    "INFO! Existing DC cert $($dccert.serialnumber) will be removed from local store"
    
    #Delete existing cert
    remove-item $dccert.pspath
    
    If ($?)
        {"SUCCESS! Removed old certificate. Triggering autoenrolment for new cert.."
        
        #Trigger autoenrollment
        certutil -pulse
        
        #Get local certificate store
        $my=dir cert:\LocalMachine\My
    
        #Check for active certificate using Domain Controller Authentication template
        $dccert=$my | where-object {($_.Archived -eq $false) -and (($_.extensions.item("1.3.6.1.4.1.311.21.7").format(0)) -match " Domain Controller Authentication")  }   
        
        "INFO! DC certificate is now $($dccert.serialnumber)"
        }
    
    Else
        {"ERROR! Unable to remove existing certificate"}
    

    ================================================================================

    Q3: If the root CA is an offline root CA (standalone root CA), then you must publish the root certificate into AD:
    certutil -dspublish RootCACertifice RootCA

    This will then use the autoenrollment settings to distribute the certificate to the trusted root store of all domain joined clients.

    If the root CA was joined to the domain, this will eventually happen automatically, but it can take up to 8 hours (default GPO application time). To force the issue, reboot a client computer and it will pick up the root CA certificate. Typically, I will plan for an overnight period to allow distribution to fully populate all machines.

    Q4. Those entries are not automatically removed. The only thing that is automatically adjusted / removed / modified during the removal is the pKIEnrollmentService object, which is removed. This prevents clients from trying to enroll against the decommissioned CA. The other objects are retained because certificates that are issued by the CA are probably still outstanding.

    For Public Key Infrastructure (PKI) client computers to successfully process these outstanding certificates, the computers must locate the Authority Information Access (AIA) and CRL distribution point paths in Active Directory. It is a good idea to revoke all outstanding certificates, extend the lifetime of the CRL, and publish the CRL in Active Directory. If the outstanding certificates are processed by the various PKI clients, validation will fail, and those certificates will not be used.

    If it is not a priority to maintain the CRL distribution point and AIA in Active Directory, you can remove these objects. Do not remove these objects if you expect to process one or more of the formerly active digital certificates.

    If you do want to get rid of them and clean up in general, the steps below will point you in the right direction:

    Remove all Certification Services objects from Active Directory:

    NOTE: You should not remove certificate templates from Active Directory until after you remove all CA objects in the Active Directory forest.

    To remove all Certification Services objects from Active Directory, follow these steps:

    1. Determine the CACommonName of the CA. To do this, follow these steps:
      a. Click Start, click Run, type cmd in the Open box, and then click OK.
      b. Type certutil, and then press ENTER.
      c. Make a note of the Name value that belongs to your CA. (You will need the CACommonName for later steps in this procedure)

    2. Click Start, point to Administrative Tools, and then click Active Directory Sites and Services.

    3. On the View menu, click Show Services Node.

    4. Expand Services, expand Public Key Services, and then click the AIA folder.

    5. In the right pane, right-click the CertificationAuthority object for your CA, click
      Delete, and then click Yes.

    6. In the left pane of the Active Directory Sites and Services MMC snap-in, click the CDP folder.

    7. In the right pane, locate the container object for the server where Certificate Services is installed. Right-click the container, click Delete, and then click Yes two times.

    8. In the left pane of the Active Directory Sites and Services MMC snap-in, click the Certification Authoritiesnode.

    9. In the right pane, right-click the CertificationAuthority object for your CA, click
      Delete, and then click Yes.

    10. In the left pane of the Active Directory Sites and Services MMC snap-in, click the Enrollment Services node.

    11. In the right pane, verify that the pKIEnrollmentService object for your CA was removed when Certificate Services was uninstalled. If the object is not deleted, right-click the object, click
      Delete, and then click Yes.

    12. If you did not locate all the objects, some objects may be left in the Active Directory after you perform these steps. To clean up after a CA that may have left objects in Active Directory, follow these steps to determine whether any AD objects remain:

      a. Type the following command at a command line, and then press ENTER:

    ldifde -r "cn=CACommonName" -d "CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot,DC=com" -f output.ldf

    In this command, CACommonName represents the Name value that you determined in step 1. For example, if the Name value is "CA1 ITPRO," type the following:

    ldifde -r "cn=CA1 ITPRO" -d "cn=public key services,cn=services,cn=configuration,dc=itpro,dc=tv” -f remainingCAobjects.ldf

    b. Open the remainingCAobjects.ldf file in Notepad. Replace the term "changetype: add" with "changetype: delete." Then, verify whether the Active Directory objects that you will delete are legitimate.

    c, At a command prompt, type the following command, and then press ENTER to delete the remaining CA objects from Active Directory:

    ldifde -i -f remainingCAobjects.ldf

    1. Delete the certificate templates if you are sure that all of the certificate authorities have been deleted. Repeat step 12 to determine whether any AD objects remain.

    Important You must not delete the certificate templates unless all the certificate authorities have been deleted. If the templates are accidentally deleted, follow these steps:

    a. Make sure that you are logged on to a server that is running Certificate Services as Enterprise administrator.

    b. At a command prompt, type the following command, and then press ENTER:
    cd %windir%\system32

    c. Type the following command, and then press ENTER:
    regsvr32 /i:i /n /s certcli.dll

    This action re-creates the certificate templates in Active Directory.

    To delete the certificate templates, follow these steps.

    a. In the left pane of the "Active Directory Sites and Services" MMC snap-in, click the Certificate Templates folder.

    b. In the right pane, click a certificate template, and then press CTRL+A to select all templates. Right-click the selected templates, click Delete, and then click Yes.

    Delete certificates published to the NtAuthCertificates object:

    After you delete the CA objects, you have to delete the CA certificates that are published to the NtAuthCertificates object. Use either of the following commands to delete certificates from within the NTAuthCertificates store:

    certutil -viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key
    Services,...,DC=ForestRoot,DC=com?cACertificate?base?objectclass=certificationAuthority"

    certutil -viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key
    Services,...,DC=ForestRoot,DC=com?cACertificate?base?objectclass=pKIEnrollmentService"

    NOTE: You must have Enterprise Administrator permissions to perform this task.

    The -viewdelstore action invokes the certificate selection UI on the set of certificates in the specified attibute. You can view the certificate details. You can cancel out of the selection dialog to make no changes. If you select a certificate, that certificate is deleted when the UI closes and the command is fully executed.

    Use the following command to see the full LDAP path to the NtAuthCertificates object in your Active Directory:

    certutil store -? | findstr "CN=NTAuth"

    Delete the CA database:

    When Certification Services is uninstalled, the CA database is left intact so that the CA can be re-created on another server.

    To remove the CA database, delete the %systemroot%\System32\Certlog folder.

    That should take care of cleanup !!

    Now, about the last part of Q4, the two separate CA implementations in the same domain...

    The logic of having two separate CA implementations is typically driven by a need to stratify and differentiate which CA is issuing certificates for compliance reason. (Not the only reason, but the one I come across most often as I deal with these issues for customers).

    Assuming that is what is driving you to go this route, or is at least a possibility, the simplest answer is that it would be dependent on the certificate template's issuing CA. In other words, if we assume that certain templates are ONLY issued by a certain CA, then renewal is based on the issuing CA.

    Typically certificates are renewed by the issuing CA as a matter of standard operation.

    I hope that helps to get you moving in the right direction. If you have any additional questions, please let me know.

    Good Luck !!,

    Cheers,

    Adam

    posted in Microsoft read more