[sketch]

yeah, this isn’t working

#!/bin/sh

###variables
groupstatus=$(nireport . /groups name users | grep -w $1 | grep -w admin | wc -l)
###actions
if [ $1 = labuser ]; then
  exit 0
elif [ $groupstatus = 1 ]; then
        exit 0
else

killall loginwindow

fi
exit 0

[sketch]

shhhhhh

Anyhoozle… any ideas on how to foce them out? Would it simply be

killall loginwindow

or would we be too far along by the time the loginhook runs?

[sketch]

almost there:

#!/bin/sh

###variables
username=`whoami`
groupstatus=$(nireport . /groups name users | grep -w `whoami` | grep -w admin | wc -l)
###actions
if [ $username = labuser ]; then
exit 0
elif [ $groupstatus = 1 ]; then
exit 0
else

####this is where I’m stuck. How do I best kill the logon process and return the user to the login window?

fi
exit 0

[sketch]

just to check, does the account you’re using have permission to create new computer accounts in the OU where you’re putting your Macs in?

[sketch]

There is a bug in the reporting feature of the Users and Groups plugin. If you do a search for a mac it will report back that it’s a DC, when actually it’s only a workstation. There is an attribute in AD called “userAccountControl” that sets what an account is.

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305144

Windows server reports back anything that has a value over 4096 as a domain controller, and the AD plugin inputs itself as a higher value than 4096.
Microsoft does have a hotfix for this, (thanks to our badgering,) but you need to contact them to get it.

This isn’t a show-stopper. If you view the properties of your Mac in the User and Groups MMC, and look at the role, you’ll see it’s not a domain controller.

If it is a domain controller, well you need to deal with that, but I’m betting it’s not actually.

[sketch]

I don’t understand why you want to. If a kerberos trust exists you just leave your accounts where they are, on the AD domain controllers. he Macs will be able to access the info just fine (groups tend to be a different matter)

[sketch]

OS X Server can only act as a Windows NT-style domain controller, not as an Active Directory domain controller.

[sketch]

unfortunately I can’t wait for Tiger. This update should have been deployed a couple weeks ago.

Yes, I have WGM. What procedure are you proposing?

[sketch]

Ah. gotcha. Have you looked at these articles yet?

http://www.4am-media.com/sso

and

http://www.4am-media.com/xrealm/

[sketch]

1: it’s always been my understanding that importing AD groups into WGM “breaks” the OS X server KDC

2: go into your /Library/Preferences/Directory Service/ActiveDirectory.plist file and find the key “Group Search Interval Hours” and change the value to something other than zero (each value represents hours, so if you set it to 1 it’ll update every hour).
I noticed that in some update along the line, Apple set it to 0 (without asking anyone), which has been causing a lot of people headaches.

[sketch]

ignore me

[sketch]

[QUOTE BY= MacTroll] There’s no real way to configure the AD plugin this way. You can play with it’s plist in /Library/Preferences/DirectoryServices, but that won’t really do the variable substitution that you are looking for.

If you really want to be able to do this, you can use the LDAP plugin instead. You’d have to do the Kerberos configs by hand and some other things, but this is one of the reasons why people still use the LDAP plugin for this kind of thing.[/QUOTE]

ok, but isn’t the AD plugin just an overlay for LDAP? How can I access 10.3’s LDAP to create variable mappings, so that when a system is connected using the AD plugin, the information that goes through it is then modified appropriately?

And ADMitMac may be a nice product, but it’s expensive. I’m suprised there have been no open source efforts yet to create a MS Dfs solution for Macs.

[sketch]

LINK

This is a good page which demonstrates the frustrations of many of us in the academic support field

[sketch]

There are 2 AFP over IP server products on the market that either provide kerberos support or will be providing it. One is MacServerIP and the other is ExtremeZ IP. But of course they cost $$$$

[sketch]

the users in a group need to be imported by the Mac into the local admin group which resides in the NetInfo database. This is a slow process, and gets even slower if you have a lot of users in the group, so you can’t expect to have admin rights automatically UNLESS you manually edit the NetInfo database and add the user in yourself.

As far as the SMB issue goes, first make sure that your Windows 2003 servers aren’t requiring signed communications. Then make sure you’re getting the correct TGT from your Domain Controller (use either the kerberos app or klist from the terminal). If you’re not, check the setup of your mit.edu.kerberos file.

[Author]

Posts