Search This Blog

Wednesday, August 26, 2020

Share Photos With Android Work Profile

Hello again Internet!

 In this post today I would like to do a guide on how to share items with the Android Work Profile. 

When we want to share something in Teams, Outlook, etc most people start off in the app that we are creating the communication from. In our example today we will use Teams. 

The issue is that, due to the architecture of the Work Profile, it will show an empty gallery usually. More precisely it only shows your 'Work' files to choose from.


In order to get around this and to share you personal items, assuming the Work Profile configuration allows it you need to start off in the photo you want to share. Once there you choose the share icon in the bottom left. Please note I tried to sanatize these images of any personal info so expect some red and white MSPaint skills.

EDIT: I just realized the image below may be confusing. The image below is a screen capture of the Outlook App I did earlier. The screenshot below is an image in my phones photos app, not an actual Outlook screen.


Once you have chosen to share the image the share window will come up. This can look different depending on the photo gallery app you have, device manufacturer, and even OS version. What you should see though is an option for the Work Profile. The blue suitcase in the screen grab below.


Once you choose to share the image to the Work Profile a new menu will pop up and allow you to choose which work badged app to share it to. In our test case I will choose Teams.


Once you make your selection it will open your work badged app and allow you to choose which communication channel to share the image to.



Once you choose your chat, I just chose Joe from my recent chats list, it will upload the image into the chat and you can then send it.







Hope this quick tutorial helps some of you out there and allows you to continue communicating in the ways you have been in a new Work Profile world.


Have a good one!

Thursday, August 20, 2020

App Protection Policies and Outlook Add-Ins

Hello Everyone!

Back to the technical side of the house today.

In this post I want to talk about a lesser known gap within Intune App Protection Policies, also known as MAM. 

When protecting the Outlook Mobile App there is a small hole that allows corporate data to escape the containerization policies. These are the 'Add-Ins' in the app. These loop in third party services into the Outlook App such as Trello, Wrike, Evernote, etc.


The issue is when you add these extensions you can log into them with a personal account. The App Protection Policies can not distinguish data going into this add-in. I suspect, because it is solely contained within the Outlook App itself, the policy views it as data just moving around internally into the app.

The work around for this is not great either, but its not terrible in my opinion. It really is something that should be disabled anyway for security sake. The fix itself is to remove the ability for end users to allow add-ins. The reason why this is not a 100% great fix is because this permission applies to not just Outlook App, but also OWA and Outlook desktop. 
Once you disable these permissions the user will no longer be able to select add-ins and when they try they receive the message below. 


Hopefully this can close a small hole some of you may have in your org today.

Have a good one!

Thursday, August 13, 2020

Personal Thoughts on Mobility

 The quiet side of the cloud evolution

    For a few years now the next evolution for most businesses has been the cloud. Yes, I know what you are saying, the cloud is old news and people have fully adopted the "cloud" some years ago and are on to bigger and better things like automation, a.i., IoT, and of course DevOps. This is not everyone though, this is not even the majority of businesses I interact with.

    When people think of the cloud and the benefits it offers most businesses talk IaaS, PaaS or SaaS. How can we lift and shift our infra, our apps, our business processes? What has caused less of a stir overall is the lift and shift of endpoints and management to cloud enabled, modern management platforms. This, to me, is the quieter side of the cloud.

    The next evolution of endpoint management has undergone, and will continue to undergo, massive changes. This is all driven by the changes in business functions and the changes to the way employees work. Almost gone, but not quite, are the days of assigned cubicles, restrictive and ineffective policies, and the feeling of needing a body in a seat to have your workforce be productive. These business changes driving the changing technology are only made possible in a cloud platform. 

    What do these technology changes try to solve? In short, it is about trying to increase the ability to work anywhere, from any device, while maintaining security. Your office network is no longer the security boundary, you no longer host business critical apps on your hardware with non web based logins, sprawl of shadow IT can overwhelm a business now because if there is an easier way to complete a business process than what IT offers to the end users they will find it and adopt it. 

    How do we address these needs? It all starts with Identity. With the goal of working from anywhere that tosses out the network as the security plane and from any device tosses out traditional device management. Identity is the new security and control plane as that is the common thread between anywhere and any device. This means that a true modern management solution has to have an Identity solution attached to it with deep integration, such as Microsoft Intune or VMWare's Workspace1. Without Identity your cloud enabled endpoint solution is not truly modern management capable.


Covid-19 and the great experiment

    In late 2019, into 2020, and at the time of this writing, Covid-19 is a global pandemic. Many business and workers can not work, have been furloughed, or reduced their hours. This has hit business across all sectors in a meaningful way. 

    For some business and workers its as if we have been forced into this grand experiment who's goal is to answer two questions:
1. Can you work remotely?
2. Can you do it securely?
As the world has come to find out, the answer is a pretty solid yes, we can work remotely and in a meaningful and productive way.

    Modern management can make this forced transition so much smoother for the end user and the business. The ability to use mobile platforms such as iOS and Android phones or tablets, the option to do BYOD for not just mobile but Win10 as well, and the ability to do this securely because we have the proper identity controls in place, allow the workforce to be safe and productive while allowing the admin the management and security they require at the same time.

    Is this forced experiment a success? In most ways yes, but there are some challenges. Change is hard, no matter the circumstance, and getting a traditional business to adopt modern management can be difficult in the best of times. Things are not the same in the cloud world. Reporting is different, security is different, some things are actually lacking or missing and we have to find creative solutions to these things. Because we are a cloud platform though we can move with incredible speed, making changes to the system and available controls constantly. While other products have had a handful of decades to mature, where most modern management platforms have only had roughly 5 years give or take, modern solutions are already catching up due to the power of being built on a cloud platform.

    This is all mostly just me rambling but if you have made it this far I want to leave you with a couple solid take aways. Do not be afraid to change and to adopt a mobile endpoint solution, allow your users a little more freedom in choosing where and how the way that they work, and when someone mentions the cloud remember that includes endpoint management too.

Wednesday, August 5, 2020

Azure AD Hybrid Join Over VPN Issues

Hello once again! Long time no talk...read?

In this post I wanted to talk about the way Hybrid AAD Join works over VPN and an interesting communication I had with a Microsoft contact of mine recently.

I have covered Hybrid AADJ in the past, link here. Adding in the VPN adds a new wrinkle into the equation that is supposed to be solved by one of the HAADJ scheduled tasks. 


HAADJ creates a scheduled task that runs the dsregcmd.exe command. This command is built into the Win10 OS and this task is also built into the OS and have been running since day 1. These are located at Microsoft>Windows>WorkplaceJoin. This task has 2 defined triggers


The first trigger runs the dsregcmd at the initial logon. This does not help our VPN users at all unless you are deploying a prelogin VPN like Always-On VPN or Direct Access. The second scheduled trigger is supposed to kick off every hour after a reboot and generates a log in event viewer with ID 4096





This would allow a VPN user to reboot, login, and trigger the once an hour request, and if still connected to the VPN in an hour kick off the Hybrid Join process. This was not seeming to happen though. The timings of this event were very sporadic. I brought it up to a contact I have at Microsoft and it appears there was a bug that needed fixed! I have not validated with them what version/when/how this was going to be in place but if you are having issues with VPN+Hybrid Join hopefully it should be fixed in a future build.



Until next time fellow IT explorers

Tuesday, January 7, 2020

White Listing Apps on iOS and Still Allow iCloud

Hello internet people!

Wanted to post about a recent issue that came up at a client. This particular client was using corporate owned Apple Business Manager (new DEP) devices that were being locked down with a white list of applications. This customer also wanted to allow people to sign into iCloud to retrieve their personal contacts and photos and things like that. 

The issue was every time we attempted to sign into iCloud it would fail. We narrowed it down to the white list policy by flipping the policy off and trying again, seeing a success, wiping and flipping the policy back on and seeing a failure again. 

After we had narrowed it down I did a little digging and found this gem

https://support.apple.com/en-us/HT209205

Maybe this was common knowledge, but it wasn't for me or the customer I was working with.

Sure enough after adding com.apple.CoreCDPUI.localsecretprompt to the app white list we were able to log into iCloud without issue. 

If you are wondering what I mean when I say an app "white list" inside of Intune its the show/hide application settings and looks like the image below.



Hey, I mean is the word 'secret' is in the app name it cant be that well known right?

Have a good one!


Wednesday, December 18, 2019

Android Enterprise Dedicated Devices and SCEP

Hello Everyone! 

Recently SCEP certificate authentication was released for Intune with Android Enterprise devices. This means both COPE and Kiosk devices or whatever they are calling them these days.

I just finished setting this up for a customer and let me tell you there were some challenges. I don't have any screenshots of the issues but I just want to run down a list of gotchas that we ran into to help you do the same. Once we had all other platforms working (iOS, Android Legacy, Android Work Profile) we thought Android Fully Managed would be a simple reconfig. It was not. 

1.) Deploy the sub cert out with the root, this should always be done in my opinion.

2.) Make sure the devices have a Compliance Policy assigned. Our kiosk devices originally were marked as non compliant because we did not have one assigned as they were already so locked down (this is just the way the customer had their environment configured). We were seeing the SCEP, Root, and Sub certs stuck as 'Pending'. This went on for a day or so until we got Microsoft Support on the line who suggested the Compliance policy as a general fix. He eluded that this is something he does as a baseline because of, well, just Intune being Intune. 

3.) I have done iOS kiosk devices in the past that are without user affinity and I have used the DNS attribute in the same name historically. You can not do that with Android from what I have found. The WiFi settings on the device itself will not recognize a certificate unless it has the UPN in the SAN name. It will never even attempt a connection if you give it a DNS SAN cert.

4.) This could be just coincidence but we supplied an external identity in our WiFi profile as well. We just used a generic name of Android Kiosk and once it actually authenticated the identity changed to {{serialnumber}}@domain.com like it was supposed to

5.) We had some issues with time outs attempting to fetch the SCEP certs and WiFi policies. We were able to solve this by syncing from both the Intune app and the built in Android Device Policy app. My running theory on this (and im sure I am going to butcher it) is that the Intune certificate connector doesn't look at any Google API syncs from the Device Policy app. So when you sync from there you receive the SCEP profile, you hit IIS, hit the connector, and then it just sits waiting for the Intune sync to validate and eventually times out. Moral of the story is to sync from both the Intune App and the Device Policy App.

This is all also assuming you have a healthy SCEP and PKI infra underneath everything which can be a task itself!

These are all just some thoughts from someone who has spent far too long poking at SCEP. 

Send help in the form of miniature paints and Chipotle.

Best of luck!


Monday, October 21, 2019

AAD Connect and Pass Through Auth Possible Gotcha

Hello again everyone!

Been awhile!

I want to make a quick post about an issue I ran into out in the field in regards to AAD Connect, Pass-Thru Auth, and log on restrictions in local AD. 

**Spoiler Alert** Read your documentation thoroughly and you can avoid stupid mistakes like this one!

Lets start off with a brief explanation on what Pass-Thru Auth is. This method of auth/ssso is similar to ADFS. When you attempt to auth against O365/Azure AD it will send the request back on premise to an agent that is installed on a member server. 

There are certain requirements that this member server needs that we wont go into in this post, such as line of sight to a DC, multiple agents for HA, etc, etc.

Now onto what the issue was.

At a client we recently had a group of users, well maybe 'users' is not the correct word for it, nor is 'service accounts'. It was a handful of user objects in AD that the security team used to log into a very specific set of workflows on premise and into a couple services in the cloud. 

They just stopped authenticating one day. 

When trying to auth against a cloud service they would receive this error 'Service is currently unavailable, please contact support for further help'

When we looked at the sign in logs inside of Azure AD this is what we saw.



We tinkered with the idea that AAD Connect was not syncing the password so we took a look at the health monitor. Everything looked good but thats when I saw they were using Pass-Thru Auth. 

We dug a little deeper and found out that this user account had a log on restriction on it in local AD that was just implemented.

(this photo from my lab, hence not sanitized. I dont care if you try to compromise Zangief, the red cyclone will pile drive you)


Well there is our culprit. When using Pass-Thru Auth and you are doing log on locally restrictions you need to add whatever server the agent is on into the log on restrictions


Once the agent servers are added you should no longer be barred from accessing any other services. If you need to lock down your cloud services for these accounts that is where Conditional Access come into play. 

Moral of the story? Check your documentation when you make a change. This is laid out in the Pass-Thru Auth doc, although it is tucked away under the 'troubleshooting' doc and not the main concept or implementation document.


Hope this helps someone else out before they waste a few hours trying to figure out what the issue is.

Until next time everyone!