We recently saw an issue with Azure AD self-service password reset (SSPR). It’s been working fine for us for ages, ever since we first configured it using DirSync, but recently users started seeing the following message:
Get back into your account
Please contact your admin
We’ve detected that your user account password is not managed by Microsoft. As a result, we are unable to automatically reset your password.
You will need to contact your admin or helpdesk for any further assistance.
As we’d made no changes, we were obviously concerned!
Initially I took the following steps to try and resolve the issue:
- Ensured that the OS patch levels of the servers (Azure AD Connect, ADFS, WAP) were up-to-date, which they were.
- Upgraded Azure AD Connect to the most recent version. The version we were running was a little behind, but not significantly so. During the upgrade process, the wizard takes you through what you’d normally see if you reconfigure Azure AD Connect and select the ‘customize synchronization options’ task. The optional features selected were still the same as we’d picked the previous time we’d upgraded, and included ‘password writeback’.
Unfortunately none of the steps taken above made any difference.
Looking in the configuration page for Azure AD in the old portal, I noticed that the ‘Password write back service status’ was still set to ‘Not configured’:
Which, bearing in mind I’d just upgraded Azure AD Connect and been through the configuration wizard and seen that this option was ticked, should not as far as I was concerned be the case.
To correct the issue therefore, I took the following steps:
- Launched the configuration of Azure AD Connect and selected the ‘customize synchronization options’ task.
- When presented with the optional features configuration page of the wizard, unticked the ‘password writeback’ option and then completed the configuration.
- Repeated the above steps, but this time ensured that the ‘password writeback’ option was ticked:
Checking the configuration page in the old Azure Portal again, the status of the ‘Password write back service’ is now ‘Configured’ and the correct SSPR prompts are again being displayed to users.
I was recently in the position that I needed to rebuild a workstation at a remote location, but wanted to end up with it joined to the domain, and able to install software via the SCCM Software Center. Enter Offline Domain Join (djoin.exe)!
Offline Domain Join allows the creation of a machine account and the establishment of a trust relationship between a computer running Windows and a Domain. As part of the process, group policy information can also be transferred to the machine that will be joined to the domain.
Assuming Direct Access is available, the appropriate group policy information for Direct Access can be transferred as part of the process, and this should then allow the remote machine to establish a connection to the domain and from there all remaining group policy information can be transferred, the Configuration Manager client installed etc.
Information on ‘djoin.exe’ including examples for use can be found at https://technet.microsoft.com/en-us/library/offline-domain-join-djoin-step-by-step
My scenario was:
- The machine account already existed in the correct OU and was a member of the appropriate groups for Direct Access (the machine name had already been used; this was a rebuild) and therefore I needed to use the ‘/reuse’ parameter.
- The only group policy information I wanted to transfer to the remote machine was for Direct Access. I anticipated that all other group policy information would be transferred automatically once a Direct Access connection had been established.
In my case, the command I used on the provisioning server were:
djoin /provision /domain domain.com /machine MyWorkstation /savefile MyWorkstation-blob.txt /reuse /policynames “Direct Access Client”
The resultant blob should be transferred securely – take note of what the TechNet page says on the matter:
The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.
On the remote workstation, the command I used was:
djoin /requestODJ /loadfile MyWorkstation-blob.txt /windowspath %SystemRoot% /localos
At this point you’re prompted to reboot the workstation. Once the reboot was complete, I left the machine for a few minutes to allow it to establish a connection, then signed in. Everything worked as anticipated and I could log in as a domain user and a Direct Access connection was established. Following a group policy update, the Configuration Manager client was transferred and installed, and a short time later the Software Center became available and I could add software made available from SCCM.
Building a Hyper-V virtual machine from scratch almost always seems to involve mounting an ISO image at some point during the installation process. I suspect that like us, many other organisations already have a network location in which we store ISO images. The ability to mount an ISO image from our usual network location saves us having to copy the ISO images to the local Hyper-V servers.
The ability to remote mount an ISO image requires that a couple of configuration changes are made. Attempting to remote mount an ISO image without making the configuration changes usually results in an err along the lines of
Inserting the disk failed
Failed to add device ‘Microsoft Virtual CD/DVD Disk’
The file ‘\\RemoteServer\Share\ISO_Image.iso’ does not have the required security settings. Error: ‘General access denied error’
There are two configuration changes that need to be made. The first is ensuring that the Hyper-V hosts can access the share itself that contains the ISO images. As a workaround, you can always grant ‘Everyone’ read access to the share. If you want to control access to individual servers, you need to specify the Active Directory computer object for each server you want to give access to.
The second configuration change that is required to to grant Constrained Delegation on the virtual host objects in Active Directory:
- Log onto a domain controller and open Active Directory Users and Computers from the Administrative Tools menu, or open the remote administration Active Directory tools from another server or client
- Locate the Hyper-V host computer object
- Right-click the object and Select Properties from the context menu
- Select the Delegation tab
- Select the ‘Trust this computer for delegation to specified services only’ radio button and then the ‘Use any authentication protocol’ radio button
- Click the ‘Add’ button:
- The ‘Add Services’ dialog will open:
- Click the ‘Users or Computers’ button and add the remote server hosting the ISO images. Click OK
- Select the ‘cifs’ service type from the list shown:
- Click OK to close the dialog, the computer object properties should look like the following:
- Click OK to apply the change
- Repeat the above steps for any other Hyper-V hosts servers.
You should now be able to remote mount ISO images from the server specified.
SharePoint can use multiple domains for user authentication, however I recently came across an issue when setting up an extranet using this scenario.
The steps for setting up SharePoint 2007 to use multiple domains for user authentication are relatively simple:
- Add the second domain as a user profile source in the SSP
- Issue the following stsadm command to encrypt the password for the account that is used to access the second forest or domain on each web front end server in the farm:
stsadm –o setapppassword –password <password>
- Issue the following stsadm command to add multiple domains to the people picker search list:
stsadm –o set property –pn peoplepicker-searchadforests –pv domain:<original resource domain>;domain:<secondary domain>,<domain>\<username>,<password> –url <web application URL>
At this point I could successfully add users from the second domain to the security groups in a site collection or site, however when I attempted to log in as one of these users, I received a “500 – Internal server error”. Logging in as a user from the original resource domain worked fine however.
Modifying the web.config file for the web application to set CallStack to true and CustomErrors to Off didn’t give me any further information, at least in Internet Explorer 8, as I still saw the same “500 – Internal server error”, however viewing the web application in Firefox gave me a somewhat cryptic error:
This error translates as STATUS_AUTHENTICATION_FIREWALL_FAILED, however the firewall wasn’t an issue in this scenario.
The solution was to grant the machine accounts for each of the web servers in the SharePoint farm an extra right in AD. The steps were:
- On a domain controller, start “Active Directory Users and Computers”
- On the view menu, ensure that the ‘Advanced Features’ option is checked
- Locate the computer account for first of the web servers in the SharePoint farm
- For the computer account, right-click and select properties and then click the security tab
- Add the <external domain>\Domain Users group to the security list and grant the ‘Allowed to authenticate’ right. Click OK to close the dialog.
- Repeat these steps for the computer accounts of all the other web servers in the farm
This resolved the issue and allowed users from the second domain to log into SharePoint.
Note that to achieve multiple domain authentication for SharePoint 2010, the same stsadm commands are used, and I therefore believe that the same issue may occur, however the above solution should also work for SharePoint 2010.
I recently saw the above error on a SharePoint 2007 install of a test system. Reading a few blog posts, it seemed that most people were reporting the error as an issue when there was a problem with communication between the SharePoint server on which the wizard was being run and the domain controller it was connecting to as its logon server.
My machines didn’t seem to have any issues talking to each other however. Just to make sure, I changed them both over to a private virtual network, but that didn’t seem to help at all.
After a bit more rummaging, it turned out that the batch file I had used to create the users I needed for the SharePoint service accounts on the domain controller hadn’t created the ‘user@domain’ format of the user account correctly.
Recreating the users manually immediately solved the problem and the wizard ran successfully.
If you store large files in SharePoint 2007 and are using webdav to access them (Explorer View uses webdav for example), you may be seeing the following error:
Cannot Copy <filename>: Cannot read from the source file or disk
If so, this relates to a registry key which is set on the local machine to limit the maximum file download size to 50Mb when using webdav. To correct this behaviour, change the value of the FileSizeLimitInBytes registry key needs changing on the client machines. To do this, follow these steps:
- Start regedit
- locate the following registry key:
- In the right pane of the registry editor, right click the FileSizeLimitInBytes key and select ‘modify’
- Enter a new value for this maximum file size (in bytes, as the key states) and click OK.
- Close regedit and restart the computer.
Instead of making this change individually on each of the client machines, this key can of course be distributed via your organisation’s group policy.
To add domain users to a local machine group using Group Policy, we need to use the Restricted Groups feature. For the example shown below, I’ll be using a Windows Server 2003 domain functional level.
- Create a new global/universal security group in Active Directory to contain the users which you wish to add to the local group on the target machines.
- Make the domain users you wish to add to the local group on the target machines members of this new group.
- Open Group Policy Editor and navigate to the OU where the target machines reside. For example, if we have a ‘Desktops’ OU which contains the machines to which we wish to add the domain users, that is the location of the group policy we need to edit or create.
- If a Group Policy already exists for the OU selected, edit the Group Policy. If there is no Group Policy for the OU selected, create a new group policy and then edit it.
- Within the Group Policy, navigate to Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Restricted Groups
- Right-click on either Restricted Groups in the left pane of the Group Policy Management Editor, or in the right pane, and select Add Group.
- The ‘Add Group’ window appears:
- Click the ‘Browse’ button to open the ‘Select Groups’ window and select the group created in step 1, above, then click OK. Click OK on the Add group window.
- The Properties window for the Restricted Group appears:
- The Properties Window has two membership areas; ‘Members of this group’ and ‘This group is a member of’. Adding users to the ‘Members of this group’ option would add domain users to the Active Directory group created in step 1, and would remove any members of that group already there. As we added the required users to the group created in step 2, we shouldn’t need to use this option. Adding group names to the ‘This group is a member of’ option adds the security group and its members to the group(s) specified.
- Click Add next to the ‘This group is a member of’ option and enter the names of the local groups you wish to have the domain users added to (e.g. Administrators, Users, Performance Monitor Users etc.) and click OK.
- To test that the above steps have worked, log onto one of the target machines, run ‘gpupdate’ from a command prompt and check the local groups specified above for the new members.