Office 2016 and AD bound 10.11 machines

[TheSeans]

So I'm required to have the namespace set to forest for all our AD Bound macs. So all my user names end up being DomainUsername

Which works perfectly fine for everything but Office 2016. Anytime I try and save anything to a user folder I get a permission/naming error due to the in the users folder.

This is on Osx 10.11.1, and Office 15.15. I'm pulling down some of my older os images to test on 10.10 and 10.9 right now.

Anyone else running into this?

[macbentosh]

Not seeing that issue...My users save locally.

[geoffreykobrien]

I ran into this with a bunch of my developers and had to move away from the forest namespace. For us it was ok because we had unique usernames across our domains.

[calumhunter]

your short usernames have a in them? Thats bad ju ju
shortnames shouldn't contain spaces or special characters

perhaps there is a way to map short name to a different attribute in AD? even the UID perhaps?

[TheSeans]

@calumhunter I know it's bad ju ju. But my network guys required me to do it. They have some filters set based on username, and the macs weren't reporting properly, so I had to turn namespace forest on. Believe me I wasn't happy about it, it's been nothing but a headache for me.

@macbentosh Are your user folders /Users/domainusername/ ?

So far my temporary solution was to rename their user folder, and then edit their user to point to the new location not containing the wretched
If I end up having to go this route, is there a way to edit the default name/path. So the user account name still ends up as domainuser, but the folder location ends up as just user?

[talkingmoose]

Sounds like there's a little more going on here.

The DOMAINusername nomenclature is normal in many places and should only affect authentication when using it at the login window. It's just a mechanism to say "I'm this user logging is from this DOMAIN." At that point, the user is authenticated and you should never really see anything different.

If your users are having problems accessing a folder after authenticating, it's probably not because of the " " but actual permissions on the folders they're trying to access.

(Your server administrator hasn't really put " " in the folder names on the server, has he? If that's really the case then Office for Mac forbids this character because it has to maintain compatibility with Office for Windows, which uses that character to denote file paths. That won't change.)

[Kaltsas]

There is a dsconfigad flag for -namespace forest

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/dsconfigad.8.html

When this is set AD mobile accounts home directory are generated on the Mac as DOMAINuser. This breaks your ability to save from Office applications among other things. We have multiple domains and users with multiple accounts with the same shortname in these different domains. I investigated using -namespace forest a bit but theres too much that breaks when configuring the AD bind in this manner. I have a script that rejiggers the search domains now and we just don't set an expectation that users should be able to log into a machine with credentials from different domains than is configured for the client.

I would suggest finding a way to reconfigure your other processes to work with the bind configured with -namespace domain.

[TheSeans]

@talkingmoose It's exactly what @Kaltsas says below you. It actually puts that at the start of all created mobile user accounts. I fought it pretty hard when I was told to implement it, even at the time I was having issues with Office 2011 and the character in user local home locations. It's an issue with Office 2016 using a custom save process that follows windows file name restrictions.

The way our network team does filtering is based off user name, and they use the domain prefix to separate BYOD and district owned devices. On the Mac side they weren't getting anything to signify that the machine was joined to the domain. I offered to feed them data from casper to match mac address of our devises to separate BYOD from district owned but got shot down.

Right now the damage is already done, thankfully I only have a small group of users who need 2016 right away, and I can adjust their accounts by hand. Even if I could get them to allow me to turn namespace forest off, all my users would create new accounts on their next login, so that would be a huge mess.

[Kaltsas]

I mean I get why it does it. For users with identical shortnames in multiple domains it would make DOMAIN1user DOMAIN2user etc... but it's pretty much a non starter since using this mode broke the most commonly used apps in all of computing. I wanted to use it since we have users with credentials in multiple domains that have the same shortname, I've never heard of that structure being a network requirement.

Breaks Microsoft Word seems like a cut and dry case for "we need to rework our procedures", not do the process that breaks Word.

@talkingmoose are you saying that you've seen Word work when configured with -namespace forest (DOMAINuser home folders)? Or just that those places are not using the Office applications? You are the resident office bonjwa if there is a way to make Word not choke on a path with I would cry tears of joy.

[calumhunter]

So basically what you are saying is that the sAMAccountName in AD is Domain1Username?

Looking at the AD plugin it doesn't look like you can change the RecordName attribute to map to a different attribute in AD. It seems hardcoded to use sAMAccountName as the name of the homedirectory

Perhaps you could do some fancy scripting to change the users home directory to a new directory based on their UID, then change the home directory to the new folder via dscl and get them to log out and log back in

you could run that as a login script that runs once per user for example.

Thats how id probably go about it