joeware - never stop exploring... :)

So in a recent blog post I recounted my experience when looking into some lockout parameters (http://blog.joeware.net/2010/03/27/2014/). One of the things that bothered me a little was that the value -9223372036854775808 decodes as “undefined” and always has. I am thinking now that I want to change that to something like “undefined/never/forever” which better describes the value.

For example:

[Tue 04/20/2010 20:18:47.41]
F:\Dev\Current\CPP\AdFind>adfind -default -s base forcelogoff -samdc

AdFind V01.41.00cpp Joe Richards (joe@joeware.net) February 2010

Using server: K8R2Dom-DC01.K8R2Dom.loc:389
Directory: Windows Server 2008 R2
Base DN: DC=K8R2Dom,DC=loc

dn:DC=K8R2Dom,DC=loc
>forceLogoff: -9223372036854775808 [undefined]

1 Objects returned

[Tue 04/20/2010 20:19:07.23]
F:\Dev\Current\CPP\AdFind\Debug>adfind -default -s base forcelogoff -samdc

AdFind V01.42.00cpp ***BETA*** Joe Richards (joe@joeware.net) April 2010

Using server: K8R2Dom-DC01.K8R2Dom.loc:389
Directory: Windows Server 2008 R2
Base DN: DC=K8R2Dom,DC=loc

dn:DC=K8R2Dom,DC=loc
>forceLogoff: -9223372036854775808 [undefined/never/forever]

1 Objects returned

My main concern to NOT do this is for people who have scripts that depend on this value. So along those lines I went with undefined as the first part of the string so that the old string is still there. Yes, you still have to change scripts but hopefully the change wouldn’t be as difficult. For example if changing a perl script with a regex…

$line=~/\[undefined\]/

to

$line=~/\[undefined.+\]/

Note the very simple basic change, addition of .+ which sucks in the /never/forever part of the string.

Thoughts? Will this change seriously break anyone?

    joe

http://blogs.msdn.com/microsoft_press/archive/2010/04/14/free-ebook-introducing-microsoft-sql-server-2008-r2.aspx

http://gps.cloudapp.net

I received an email today from someone trying to pipe data from AdFind to ExchMbx. While ExchMbx is getting a little long in the tooth and PowerShell was supposed to have killed it by now since everything is Exchange is supposed to be done via PowerShell now, seems some people are still using it.

Anyway, the issue was a relatively simple one. ExchMbx can accept a quoted DN list via STDIN for input if you want to send it a large quantity of DNs at once. To send that list of DNs via AdFind, you want to use the –dsq option. The –dn option, the –adcsv option, nor the –csv options will not work for this purpose.

However, if you want to get fancy and send in the DNs from a group’s member attribute, you can use something like

adfind –default –f name=groupname member –qlist  exchmbx blah blah

which will give you a quoted DN list that is composed of the membership if the group.

    joe

Today I saw emails from two different sources asking about AdFind not returning Extended Error information when the –exterr switch is specified. However, the information was visible in a network trace. Must be a bug in AdFind right???

Maybe…

While it could be a bug in AdFind, to date my experience is that it likely isn’t. This is especially true if you run the command on one version of the OS and you don’t see the extended error information but if you run it on a newer version of the OS you do see the extended error information.

AdFind doesn’t do anything special for the LDAP API stuff based on the client OS you are running the command from. In fact, when you ask for extended error information, internally in AdFind it simply flips a little boolean flag so that an IF statement will be true and therefore run in the event there is an error. That IF executes an ldap_get_option or an ldap_parse_result[1] asking for the error string and displays the error message if it is returned.

    joe

[1] Depending on whether or not the error came up when we were processing a result set or we were binding or what not.

http://msdn.microsoft.com/en-us/library/ff423674.aspx

This is about Windows Identity Foundation (WIF) and ADFS V2.

"An Introduction to Claims" explains what a claim is and gives general rules on what makes a good claim and how to incorporate them in your application. It’s probably a good idea that you read this chapter before you go on to the scenarios.

"Claims-Based Architectures" shows you how to use claims with browser-based applications and smart client–based applications. In particular, the chapter focuses on how to implement single sign-on for your users, whether they are on an intranet or an extranet. This chapter is optional. You don’t need to read it before you go on to the scenarios.

"Claims-Based Single Sign-On for the Web" shows you how to implement single-sign on within a corporate intranet. Although this may be something that you can also implement with Windows integrated authentication, it is the first stop on the way to implementing more complex scenarios. It includes a section for Windows Azure™ that shows you how to move the claims-based application to the cloud.

"Federated Identity for Web Applications" shows you how you can give your business partners access to your applications while maintaining the integrity of your corporate directory and theirs. In other words, your partners’ employees can use their corporate credentials to gain access to your applications.

"Federated Identity for Web Services" shows you how to use the claims-based approach with Web services, where a partner uses a smart client rather than a browser.

"Federated Identity with Multiple Partners" is a variation of the previous scenario that shows you how to federate with partners who have no issuer of their own as well as those who do. It demonstrates how to use the ASP.NET MVC framework to create a claims-aware application.

  joe

Pretty nice Kerberos FAQ available at

http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html

   joe