10-04-2013 05:16 PM
I thought maybe I'd have some luck on the first try with this but alas, it was not to be.
Right now I am getting "invalid usernaem or password" when trying to Add a drive in BB Work Drives, and the credentials are just fine. According to this KB article, you have to grant the Allow log on Locally right, under your BES10 server's Administrative Tools > Local Security Policy > Local Policy > User Rights Assignment.
When I do this, all options are greyed out. This I believe is because this is a domain member, not a standalone server as this article was probably written with. However if I go to GPMC, create a new GPO, I can find an entry in:
Computer Management > Windows Settings > Security Settings > Local Settings > User Rights Assignmen, and there is an Allow log on Locally entry there. If I edit it, there are by default no users or groups in trhe list, so I must put acheckmark in Define These Policy Settings, to be allowed to Add a User or Group.
Not knowing any better, I created a Global security group in ADUC, added my BB users there, and then added it to this GPO. Upon clicking Apply, I was prompted with a bit of an error saying Administrators must be granted log on locally as well - this is a concern since as a domain admin I already have that, so I thought perhaps setting these explicit entries would somehow screw everything up in AD so I canceled out.
At this point I have no idea what to do. I'm also a little puzzled why this non-default setting, that is obviously required by 100% of environments that want to use Work Drives, is not mentioned in the Work Drives user guide. Maybe ther's an admin guide? I looked at the BDS 10.1.3 admin guide, but there's no technical setup discussion in there on this subject. .
Does anybody have any ideas what to do? Thank you.
10-07-2013 10:15 AM
While you can allow it, i would not on a DC. A DC should be on its own dedicated VM or box unless you are running SBS which is an all in one OS.
10-07-2013 11:30 AM
Not much choice unfortunately - this VM is a secondary DC for another VM which is a primary DC. There wasn't much choice in having things this way unfortunately.
Is there some form of log I can view to see more details I wonder? All this app gives back on the front end is a failry useless "invalid username or password" error. Since the user/pw are fine, at least in the format I would expect it to be asking for (gfranklin for example), either there's an undocumented username format I don't know of, or there's a back-end problem which I can't narrow down.
For the hostname ,I've tried the internal IP, the UNC path (although this app seems to want only forwardslashes, I tried both just to see).
I'll check the event viewer on the Windows server but haven't done much with log viewing on BB before...
Also since this is a bit of an urgent scenario, as a backup I'm considering contacting paid support if they can remote in and just make it work, is that an option for RIM-developed apps though?
10-07-2013 03:51 PM - edited 10-07-2013 05:16 PM
I used this format
for hidden share
/ or \ for server entry dont seem to matter at the moment on My Z10
10-07-2013 04:59 PM - edited 10-07-2013 05:01 PM
Thanks for the info. No luck on my end, though I am kicking myeslf a bit for not thinking of specifying ht econtext for the username. Either way, both the netbios domain name format ABC\username and ABC.local\username didn't work. Tried varying the slashes just to see, no change either.
But to confirm, we're talking all internal server naming right? I mean, Work Drives is communicating with BDS, which takes care internally of resolvinv the internal server name and all that. I tired just IP of the server with no difference.
I'm really at a loss, and have no idea how to troubleshoot either. I went to the RIM\Logs folder but can't really make any sense of that stuff, so many folders and for different components of the architecture.
And surprisingly there's absolutely nothing useful anywhere vi a Google searches, Crackberry forums, etc. I tseems everybody has no problem making this work.
PS: Edited to mention, your hidden share line, was it supposed to have a $ at hte end? My share isn't a hidden one but still good to know if the format is still standard.
10-07-2013 05:17 PM
did you publish work drives from BES for the work space?
it wont work if installed on personal side
10-08-2013 10:32 AM
Yeah, all that was taken care of. I'm narrowing the problem down and so far it appears just to be permissiosn-related.
What is odd is that if I go so far as to add the AD group Everyone to have Full Control over the share, and NTFS permissions for this folder, nothing. But if I put the test user into the Administrators group, suddenly it works. I do not yet know if this alone is why it worked, or if also putting a GPO filtered to apply to just this server, doing hte Allow Log on Locally thing, was also needed. I've since disabled the GPO to test, but it still works, so I don't know if that's just a replication thing. I did gpupdate /force while on the server that hosts the share (which again is also a DC), but it still works so I am not sure if perhaps more replication time is needed, or maybe this GPO just had nothing to do with it to begin with. To reiterate, the GPO on it's own, set a day or more ago, had done tnothing, but as soon as this user was added to the DOMAIN\Administrators group, it began working.
Now I just have to figuer out how to let this user access the share(s), but not be an Administrator, since I can't put all users as admins.
10-08-2013 11:55 AM
thats odd as i can access a read only share on a File server which has authenticated users read only
I do have a dedicated BES server though
10-08-2013 02:46 PM
Well it seems I am noarrowing down on a solution. One must edit the Default Domain Controllers Policy and drill down to that User Rights Assignment > Allow Log on Locally item, and add a user or group there. Once done, Work Drives works. However I don't want toallow this permanently, I want it just to apply to this one DC since it hosts BES10.
I tried creating a new GPO with the same setting, linked it to the domain, set in the Security Filtering part of GPMC for this particular GPO to apply only to the computer (the server), but it didn't work. I did do gpupdate/force on the DC, which through other testing has proven to work immediately 100% of the time, so I trust it to work, yet the GPO didn't work.
I'm not sharp on GPO overlaps though - how would one accomplish this desired outcome, to have the Default Domain Controller Policy stay as is due to the other settings it ihas, but have this one Allow Log on Locally setting overwritten by another GPO? Assuming that is the right way to go about this.
Also what might the security implications be for leaving this as-is, that these BB users can Log on Locally to a couple of DCs? First of all they are both VMs and they can't log onto teh host, so there's no physical interface short of RDP I'd think. But maybe file system access is now available in some way?
10-08-2013 03:25 PM
Any account with the Allow log on locally user right can log on to the console of the computer. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.