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 logon path
And a new attribut in the LDAP samba account :
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.
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
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
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.