In a Terminal Server environment, there are two profile path : - the classic profile path - the profile path for the TSE Samba in its PDC role knows only the first one.
Created attachment 411 [details] LDAP Backend Terminal Profile Path Workarround With two new directives in the configuration : terminal servers terminal logon path And a new attribut in the LDAP samba account : sambaTerminalProfilePath It's not an implementation of the microsoft terminalprofilepath setting just a workarround to have a different profile path on terminal servers. If the client machine is in the "terminal servers" list, the profile path is taken from the sambaTerminalProfilePath attribut of the ldap samba account or in the "terminal logon path" setting by default (and not from the sambaProfilePath or th "logon path" setting). Hope it'll help somebody.
Jim, could you make a call on what to do about this (or just provide some advice) since you have been working on the mungedDial issues lately? Thanks.
Before I give any opnion or make any call, I have to first say I've only tested that we do the correct set and retreive of this from usrmgr. I've been running under the assumption that WTS will be extracting the correct path, rather than us. I'd have to look at WTS logons in ethereal first to be comfortable with making a decision. Yohann, is the reason you coded this because we're handing the wrong data to the TS, or because mungedDial itself wasn't working (I've just fixed that part)?
I hadn't seen mungedial attribute before coding that. After a discussion in samba-technical, I've tested mungedial and it seems to work but the problem is I cannot manipulate terminalprofilepath without the tse usrmgr tools and there is no default value. I am preparing a migration from NT4 PDC to Samba PDC and the net vampire command line doesn't take care of mungedial attribute. I have to set up each account by hand for TSE settings.. Hopefully I have "only" 300 users... With that little patch which is not very nice, It's more simple. But I understand it's not interesting for Samba Team.
Perhaps we need to look into embellishing vampire then...I agree that having to manually move these settings over isn't any fun. In terms of the tool stuff, I'd rather us figure out with clarity the format of the munged dial string and mess with that, instead of jury-rigging a way around it. I know you've started some of that work, but it looked like there was more to do? yes?
I've no problem with that. If I had known that attribute (mungedial) existed, I wouldn't have coded that (sorry for my english...I hope you understand what I write). I have looked at that attribute and It is very dark. Is it common with Microsoft to have such a format ? How to understand it and how to proceed to find its syntax ?
Well, generally the way to go about this is to 1) watch traffic from a PDC to a TS when a user is logging on 2) play with usrmgr, one function at a time, and see what the resulting changes are in mungeddial It's hard work...or I should say, a lot of tedious work.
I'm closing this one. The terminal server support is ongoing and since we are addressing the profile path work in a different fashion, there's not a lot left in this bug.